SECURITY OVERVIEW

Security and data handling in QualityOps

Everything below is implemented in the product today. Where a control belongs to your own Microsoft tenant rather than to QualityOps, this page says so — and the closing section states plainly what it does not claim.

IDENTITY: Microsoft Entra ID
ISOLATION: Per organization, in every query
SESSION: Ends after eight hours
RETENTION: 365 days, then redacted

IMPLEMENTED CONTROLS

What the product enforces.

Each item below is a property of how QualityOps is built rather than a commitment in a policy document. They are grouped in the order a security review usually asks for them.

IDENTITY AND ACCESS

Who you are is asserted by Microsoft, not by us.

Sign-in goes through Microsoft Entra ID. QualityOps has no password field, stores no password, and never receives one.
The permissions requested at sign-in are delegated and minimal: the signed-in user's profile, their mailbox, and sending mail as them. QualityOps requests no directory-wide or application-level mailbox permission, and can reach no mailbox its own user cannot already reach.
A session lasts eight working hours and then ends. The signed-in user is re-read from the database on every request, so a removed account stops working immediately rather than when its session would have run out.
Multi-factor authentication, conditional access and device compliance are policies your Microsoft tenant administrator sets and Microsoft enforces at sign-in. QualityOps neither configures them nor overrides them.

TENANT ISOLATION

Another organization's record does not exist for you.

Every business record carries the organization it belongs to, and every read names that organization in the query itself rather than checking ownership afterwards. A record in another organization is reported as not found, not as refused.
The organization you are working in is proposed by a cookie and never trusted. Membership is re-read from the database on every request, so a withdrawn membership takes effect on the next page load.
Routing is not authorization. The edge layer only decides where a visitor without a session lands; every access decision is made on the server, on every request and every change.
Cross-organization access is covered by tests that run two real organizations against the live server boundary, not against a mock of it.

DATA HANDLING

What is kept, what is never kept, and for how long.

The full body of an incoming message is never stored: there is no column to put one in, and adding one is forbidden by the codebase's own rules. Only the bounded fragment a rule matched on is retained, and it is removed under the retention policy.
What survives is the decision and its evidence: which rule matched, the bounded fragment of text it matched on, and where. That is what makes a decision explainable a year later without keeping the message.
Mail attachments are never fetched and never stored.
Microsoft access and refresh tokens stay on the server. They are never returned to a browser, embedded in a payload, or written to a log — a failed call is recorded as a classification code, never as the provider's response.
Personal data captured from mailbox intake is redacted after 365 days, counted from when the message arrived. Data attached to work that is still open does not expire while that work is open.
Retention redacts rather than deletes: the record that a decision was made survives, and the personal data inside it does not.

AUDITABILITY

Every change carries who, what and when.

Every change writes an append-only audit entry in the same database transaction as the change it describes, so the two commit together or neither does.
Audit entries carry a classification, the record they concern and the person who acted. They never carry message text, recipient addresses, phone numbers, spreadsheet contents, or file locations.
Work performed by the system is credited to the system. A machine action is never attributed to whoever happens to own the connection that triggered it.
Each job also carries an append-only timeline, from creation to closure, written alongside the audit trail rather than derived from it.

INTEGRATIONS

Every inbound integration is verified before it is read.

Billing events are accepted only after their signature is verified against the raw request body, before anything parses it. Subscription state is written by verified events alone and is never taken from a browser.
Inbound WhatsApp messages are accepted only after the provider's own signature check passes, computed over the exact bytes received and compared in constant time.
A message is acted on only if it arrives from a number an administrator has authorized for that organization, matched exactly. Each authorized number carries a durable rate limit that survives a restart.
Microsoft Graph is reached only from the server. No browser in this product holds a Graph token or calls Microsoft directly.
An instruction sent over a messaging channel that would change a job's state is challenged with a single-use, expiring code bound to the number and the person who asked for it.

APPLICATION SECURITY

Enforced on the response, not left to the page.

An enforced Content Security Policy is served on every response, alongside frame denial, protection against content-type sniffing, a referrer policy, and a permissions policy that switches off camera, microphone and location.
That policy holds the browser to this origin: it may not open a cross-origin connection, rewrite the document base, submit a form off-site, embed a plugin, start a worker, or be framed by another site.
Session cookies are same-site, and the endpoints that accept uploads additionally refuse a request whose origin header does not match this site.
Every payload arriving from outside — a form, a webhook, a Microsoft response, a query string — is checked against a schema before any code reads it.
Uploaded spreadsheets are read under explicit limits on size, entry count and expansion, so a small crafted file cannot expand into an unbounded one.
Errors are recorded as classifications. Raw error objects are never written to a log, because a driver or provider error can carry a connection string or a credential inside it.

ROLES AND AUTHORIZATION

Four roles, decided on the server.

Access inside an organization is granted by role. Every role check runs on the server, inside the one factory every change in the product is built on, before that change's own code runs.

ROLE	WHAT IT CAN REACH
OWNER	Everything an administrator can do, plus billing and the subscription itself.
ADMIN	Members and invitations, mailbox connections, authorized numbers, report and pricing configuration, and the activity trail.
MEMBER	Day-to-day work: jobs, customers, reports, quotes and the review queue.
VIEWER	Read only. No change in the product is ever gated at a level a viewer meets.

Roles are granted inside QualityOps, per organization. They are not derived from your Microsoft directory: an administrator there is not automatically an administrator here, and a directory role change alters nothing in QualityOps.
There is no client-side gate a browser could skip. The check happens before the change runs, on the server, every time.
Authorization fails closed. A change is refused unless the organization is entitled to it and the role clears the bar the change requires.

RESILIENCE AND DESIGN

Recovery has been exercised, and decisions are reproducible.

Two properties a reviewer usually asks about last, and the ones easiest to overstate. Both are described here at exactly the level they have actually been established.

RECOVERY

Tested, and described as a test rather than a promise.

Database recovery has been exercised as a drill: a historical recovery point was restored into a separate, isolated target, and the restored schema, data and migration state were validated there.
A release is rolled back by redeploying the previous build. Schema changes are made additively, so the previous build keeps running against the current database.
No recovery-time, recovery-point or availability commitment is offered on this page. Those are contractual terms, and QualityOps does not offer them today.

DETERMINISTIC PROCESSING

The same input and the same rule version give the same result.

The rules that read an email, a shift report or a sorting message are deterministic. No model decides anything in those paths, and no clock, network call or random value can change what they produce.
Rule sets are versioned, and every value a rule extracts records the rule that produced it together with the text it matched. A decision made last year can be explained with the rule that was in force when it was made.
Where a rule cannot read something with confidence, the product refuses and names the reason. Uncertainty becomes an item for a person to resolve, never a guess — sender attribution in particular is an exact match or nothing at all.

BOUNDARIES

What this page does not claim.

A security page is only worth reading if it is willing to say where it stops. Each line below is a limit we would rather state ourselves than have a reviewer discover.

QualityOps has not been independently assessed or audited by a third party, and holds no formal attestation. This page describes controls; it is not a substitute for an external review.
Nothing here is a warranty or a contractual commitment. It is a description of how the product is built at the time of writing.
No availability, recovery-time or recovery-point commitment is offered.
Storage-level encryption is a control our infrastructure providers operate under their own terms. It is not restated here as something QualityOps enforces.
The audit trail is append-only within the application. It is not an externally witnessed or independently sealed log.
Sign-in beyond Microsoft Entra ID, automated user provisioning, and roles driven from your directory are not implemented.

Questions from your security team?

Send the questionnaire, the architecture question, or the finding straight to us. A report of a suspected security issue reaches the same address.

Email us Back to the product overview

MICROSOFT ENTRA ID · ORGANIZATION-LEVEL ACCESS · SERVER-SIDE AUTHORIZATION