Last updated 10 October 2026 (tenth revision).
This notice describes what the product actually does, written from the implementation rather than from a template. Every statement in it about what the product and our systems do is one that the code, or configuration we have checked and recorded, supports today — see What this document asserts at the end, which lists the main ones and where each can be checked.
It has not yet been reviewed by counsel, and it is not legal advice. Where your organisation needs a formal data processing agreement, ask us: we would rather tell you where something stands than publish a placeholder.
Two claims a normal template would make and this one does not, because they are not true: that your data is deleted automatically when you disconnect, and that everything we hold is kept for a fixed period. What is true instead is set out under How long we keep it: deletion happens on request, fixed retention periods apply only to sign-in links, sessions and other sign-in state, to our own copies of Monitor emails and to the backups the current service makes, and such a backup is gone about four months at most after it is made.
Who we are
Defenssive Cybersecurity LLC provides Defenssive AI Security Manager, a service that reads the security configuration of your Microsoft 365 and Microsoft Entra ID tenant and reports where it differs from published security baselines — principally the CISA Secure Cloud Business Applications (SCuBA) baselines. On the Monitor plan it also reads the configuration of the Microsoft Azure subscriptions you choose.
We are the data controller for the account information you give us, and a data processor for the tenant information we read on your instruction.
What we read from your tenant
Access is granted by an administrator in your organisation through Microsoft's own admin-consent screen, which lists every permission before it is approved. It covers three Microsoft services: Microsoft Graph, Microsoft Defender for Endpoint and Exchange Online. Every Microsoft Graph and Defender permission is read-only. The two Exchange permissions are not read-only by name, and what keeps our use of them read-only is described in their own section below rather than glossed over. We also read your Microsoft Teams settings, which needs no permission of its own: see Microsoft Teams below. On the Monitor plan we read the configuration of the Azure subscriptions you choose, which needs no permission on that screen either: see Microsoft Azure below.
Microsoft Graph
| Permission | What it lets us read |
|---|---|
Directory.Read.All |
Users, groups, domains, directory roles, licences, the applications in your tenant with the permissions granted to them, and the password protection settings (the custom banned password list and smart lockout) |
Policy.Read.All |
Conditional Access, authentication methods, authorisation and app-management policies, and the Microsoft 365 idle session timeout |
RoleManagement.Read.Directory |
Directory role assignments, including eligible ones held through Privileged Identity Management |
SecurityEvents.Read.All |
Microsoft Secure Score |
AuditLog.Read.All |
Which authentication methods each account has registered |
DeviceManagementManagedDevices.Read.All |
Each enrolled device's name, operating system and Entra device ID, whether it is compliant, whether it is company- or personally owned, how it is managed, and when it last checked in |
SharePointTenantSettings.Read.All |
Your tenant-wide SharePoint and OneDrive settings (the checks use only those about sharing, sign-in and sync) — not your files, and not who has shared what |
DeviceManagementConfiguration.Read.All |
Your Intune compliance policies and device configurations: which exist, what they require, and whether they are assigned |
DeviceManagementApps.Read.All |
Your Intune app protection policies for iOS and Android, and whether they are assigned — not the apps on anyone's device |
Policy.Read.DeviceConfiguration |
Your device registration settings: who can join devices to Microsoft Entra, who becomes a device's local administrator, the device limit per user, and whether Microsoft Entra LAPS is on — not any device's password |
AccessReview.Read.All |
Your access review definitions: which reviews exist, what they cover, how often they recur and whether they apply their decisions — not who was reviewed or what was decided |
An earlier version of this application requested eleven Graph permissions, six of which no check ever read. They were removed rather than kept in case they became useful, because a permission nothing reads is access we cannot justify asking for.
Of those six, one is requested today — DeviceManagementManagedDevices.Read.All, which the Intune
device compliance check reads. Not speculatively: Microsoft returns the fields the device
checks need as EMPTY rather than as false without it, so a compliance check written without the
permission would have reported every device in a tenant as non-compliant. The permission is the
difference between a wrong answer and no answer.
Five of the six are not requested — ThreatHunting.Read.All, SecurityIncident.Read.All,
InformationProtectionPolicy.Read.All, IdentityRiskyUser.Read.All and Reports.Read.All.
Nothing reads them, so nothing asks for them.
Two permissions were requested for a time with nothing reading them, and were removed on 7
September 2026: SecurityIncident.Read.All, one of the six above, and
DeviceManagementConfiguration.Read.All. An earlier
version of this notice listed both. Removing a permission from our application stops it being
requested, but does not withdraw a grant your tenant has already made, so if your organisation
connected before that date your tenant may still show SecurityIncident.Read.All as granted. The
product does not use it. An administrator in your tenant can revoke it; ask us and we will tell you how.
DeviceManagementConfiguration.Read.All is requested again, now that checks read it: the Intune
configuration checks read your compliance policies and device configurations with it, together with
DeviceManagementApps.Read.All. Until an administrator in your tenant approves these two, those checks
are shown as not assessed. They read how Intune is configured, not what is on any device.
Policy.Read.DeviceConfiguration and AccessReview.Read.All were added on 9 October 2026 for the
device registration and access review checks. Until an administrator in your tenant approves them,
those checks are shown as not assessed. On-premises directory synchronisation settings are not read:
Microsoft gives them only to a signed-in Global Administrator, never to an application.
DeviceManagementServiceConfig.Read.All was requested on 9 October 2026 for one Intune setting and
removed the same day, because Microsoft does not return that setting to an application, so nothing read
it. If your organisation approved Defenssive's permissions that day, your tenant may still show it as
granted. The product does not use it; an administrator in your tenant can revoke it.
SharePointTenantSettings.Read.All reads your tenant-wide SharePoint and OneDrive settings, and the
checks use only these: how widely files may be shared outside your organisation, whether people
outside can re-share them, whether sharing is limited to approved domains, whether apps that use
legacy authentication are accepted, whether inactive browser sessions are signed out, and whether
OneDrive sync is limited to your organisation's computers. It does not grant access to any file, any site, or any record of who has shared what — reading those
would need Sites.Read.All across every site, which is a far wider grant than these settings are
worth and is not requested.
Microsoft Defender for Endpoint
| Permission | What it lets us read |
|---|---|
Machine.Read.All |
Your onboarded devices, and the health of their Defender sensor and antivirus |
SecurityRecommendation.Read.All |
Defender's secure-configuration recommendations for those devices |
Vulnerability.Read.All |
Known software vulnerabilities Defender has found on them |
Score.Read.All |
Defender's exposure score for your organisation |
All four are read-only. Defender also offers permissions that act on a device — isolate it, scan it, restrict what runs on it, open a live-response session — and none of them is requested. The product refuses to use an access token that carries one, even if an administrator granted it.
The last three are needed only by the vulnerability, misconfiguration and exposure checks. If your
consent screen shows Machine.Read.All alone, those three checks report that they could not read,
rather than reporting your devices as clean.
Exchange Online
| Permission | What it is used for |
|---|---|
Exchange.ManageAsApp |
Reading Exchange Online settings: mailbox auditing, the audit log, SMTP authentication, automatic forwarding, sharing policies, connection filtering, preset security policies, anti-phishing, anti-malware, anti-spam and outbound spam policies, Safe Links and Safe Attachments policies, transport rules, Safe Attachments for SharePoint, OneDrive and Teams, modern authentication, MailTips, Outlook on the web mailbox policies, role assignment policies, the report submission policy (where reported Teams messages go), your accepted domains and DKIM signing |
Exchange.ManageAsAppV2 |
Nothing: Microsoft documents it for its newer Exchange Online Admin API (adminapi/v2.0), which the product does not call |
Neither permission is read-only by name, and we will not describe them as if they were. Each lets an application act on Exchange with whatever directory role your organisation assigns to it. Two things keep our use of them read-only:
- the role you assign. Our setup asks for Global Reader or Security Reader. Both are read roles with one exception Microsoft builds into each: they can also configure Service Health, in the Microsoft 365 admin center and in Azure. The product never uses that; it sends only read requests. The product checks the directory roles it actually holds in your tenant and reports a High finding against us if any of them is not one of those two. (It does not yet inspect Exchange's own role groups, which are a second way to grant Exchange access; our setup does not ask for one.)
- the commands we send. The product sends only a fixed list of read commands (each begins
Get-), with no parameters. A command that changes anything is not on the list, and the product refuses to send one.
Microsoft Teams
No permission is requested for Teams. Microsoft documents that reading Teams settings as an application needs no permission on its Teams admin service; what the application may do there comes from the directory role your organisation assigns, the same role described above. The product reads Teams through the service Microsoft's own Teams PowerShell module uses, and reads four things:
- your Teams client settings: whether people can email messages into channels, and which outside cloud storage services (Box, Dropbox, Egnyte, Google Drive, Citrix ShareFile) they can add;
- your meeting policies: whether anonymous people can join or start meetings and chat in them, who skips the lobby, who can present, whether outside participants can take control of a shared screen, and chat with untrusted organisations;
- your messaging policies: whether people can report a security concern about a message;
- your external access settings: whether people can chat and meet with other organisations (and which ones), with personal Teams accounts, and with tenants that hold only trial licences.
Policy settings only: not chats, meetings, recordings, files, or who is in which team. Two things keep this read-only: the role you assign, which is a read role, and the requests we send, a fixed list of four read requests that the product refuses to go beyond. An access token for the Teams service that carries any permission is refused. Teams settings have been confirmed readable with Global Reader; whether Security Reader alone is enough has not yet been confirmed.
Microsoft Azure (Monitor plan only)
No permission is requested for Azure, and nothing in Azure is read until you choose a subscription. Azure grants access by role, one subscription at a time. The product reads a subscription only where your organisation assigns our application Azure's built-in Reader role on it, and only while your workspace is on the Monitor plan; on any other plan it does not contact Azure. Reader lets an application see how resources are configured, and Microsoft describes it as allowing no changes. It does not open what your resources hold: not the contents of storage accounts or databases, and not the secrets, keys or certificates kept in a key vault.
The assessment is made by Prowler, open-source software (Apache License 2.0) that we run on our own server. It is a program, not a service: your Azure configuration is read by it there and kept by us. About once a week, and whenever you start an assessment, it reads the configuration of each subscription you chose across twenty Azure services — among them storage accounts, networking, virtual machines, SQL, PostgreSQL, MySQL and Cosmos DB databases, Key Vault, App Service, Kubernetes Service, monitoring and activity log settings, role assignments on the subscription, and Microsoft Defender for Cloud — and compares it with Prowler's published checks. It does not read your Entra ID through Azure; our own checks cover Entra ID.
The key our application signs in with stays in Azure Key Vault. Prowler receives only a signed statement that lets it sign in to your tenant alone and expires within minutes, and is given a fresh one while it runs. An access token for Azure that carries any application permission is refused. Removing the Reader assignment stops the reads of that subscription once Azure applies the change; a run already under way can finish.
The consent screen is the authority
The lists above should match Microsoft's consent screen exactly. If they do not, believe the consent screen — it is the authority on what was actually granted — and tell us, because a mismatch here is a defect in this document.
We also use standard sign-in scopes (openid, profile, email, offline_access, User.Read)
for the people who sign in to our own application.
What we cannot do, as a consequence of holding only these permissions and sending only these commands:
- read anyone's password — Microsoft does not expose them and we never receive one;
- read the contents of mailboxes, files, chats or calendars;
- send mail as anyone in your organisation;
- change any setting in your tenant, including the ones we report on.
What we store
Findings — which baseline policies and additional security checks your tenant does not satisfy, their severity, and when each was first and last observed.
Evidence — the specific configuration each finding rests on. A domain name and its password expiry period; which authentication methods are enabled; the accounts holding a privileged role. This is the part that identifies things and people in your organisation.
Azure assessment results (Monitor plan) — each weekly run's results: the Azure resources it looked at (subscription, resource group, name, identifier and region) and Prowler's verdict and explanation for each check. We keep them so that the daily assessments between weekly runs can use them; findings from them say when Prowler made them.
What your team records in the product — for example, a finding set aside as an accepted risk and the reason typed for it, or who a finding is assigned to.
Account information — the names and email addresses of people who sign in to us or are invited to a workspace, the Microsoft account they sign in with, their workspace membership, their notification preferences, and their session records (including the IP address and browser each session came from).
Email delivery problems — we have built a way for our email provider to tell us when a notification email bounces permanently or is marked as spam, or when it stops sending to an address for another reason, such as an unsubscribe through the provider, so that we stop sending weekly summaries and change alerts to that address; sign-in links, invitations and the note when an assessment finishes would still be sent. It is not switched on yet, so today we receive and record no such report.
Email log — each email we send: the address it went to, which kind of email it was, when, and whether our provider accepted it; never the message itself or a sign-in link.
We do not copy your mailboxes, documents or messages. From your tenant, we store what a security configuration report needs and nothing it does not.
How it is protected
Some of what we store is encrypted before it is written to disk: the evidence behind each finding, the detail of each assessment, the Azure assessment results, the reports we seal after each assessment, and weekly summaries waiting to be sent. Each workspace has its own data key; that key never exists in plaintext at rest, and is itself wrapped by a key held in Azure Key Vault: our servers can ask the vault to unwrap a data key, but never receive the vault's key itself. In a copy of our database, those fields are ciphertext without separate access to that vault.
The rest is not encrypted by us. That includes email addresses, workspace names, your tenant's identifier, which findings your tenant has and their severity, our audit records of who did what and when, and what your team types into the product, such as the reason for setting a finding aside and the emergency and service accounts you list. Microsoft Azure encrypts the storage our backups are kept on, with keys Microsoft manages. That protects against theft of the physical media, not against someone who can reach our server or our backups.
One customer's data cannot be read under another customer's credentials. This is enforced by the database rather than by application code: every table holding your findings, evidence, assessments and what your team records carries the workspace it belongs to; row-level security is enabled and forced on those tables and on the tables holding account and email records; and a query runs under a capability that names one workspace and cannot name another. The rule is tested automatically on every change pushed to our code repository, and our recovery procedure runs the same test against a restored backup.
Nobody signs in with a password. Access to our own application is by single-use email link or by Microsoft sign-in. We never receive, store or transmit a password of yours.
What withdrawing consent stops, and when. Your administrator can withdraw our access by deleting our application under Enterprise applications in the Microsoft Entra admin center. Microsoft then stops issuing us new access tokens for your tenant. It does not cancel a token it has already issued, and we reuse a token until shortly before it expires rather than fetching one for every read, so reading can continue until that token expires, at a time Microsoft sets when it issues the token. (Microsoft's Access tokens page gives a default of 60 to 90 minutes, but says it does not apply to tokens for Microsoft's own services, such as Microsoft Graph, which ours are.) Removing only the directory role you assigned us leaves our Microsoft Graph and Defender permissions in place. Closing your workspace stops our reading sooner: the product then refuses to use your connection, so nothing new is read from your tenant, though a read already under way can finish.
Where it is processed
In Microsoft Azure, in the East US region — data storage, backups, and processing. Backups are held in the same region.
How long we keep it
Your workspace's data — findings, evidence, assessments (including the Microsoft Secure Score read with each one, and the Azure assessment results), reports and what your team recorded — is kept for as long as the workspace exists, and until you ask us to delete it.
Closing a workspace is not deleting it. An owner can close a workspace in Settings. That stops every assessment and email, disconnects your Microsoft tenant on our side (our application stays in your tenant, with the access you granted it, until your administrator removes it), and signs everyone out for good. The data stays in our database, no longer reachable through the product, until deleted on request.
To have your data deleted, ask us. An operator deletes a closed workspace on written request: its encryption keys are destroyed in our live database, every record belonging to it is deleted from our live database — including our own audit records about it — and so are the accounts of people who belong to no other workspace (an account another workspace's records still refer to is kept). What remains in our live database is a record that the deletion happened and when, with no content, names or addresses, and the sign-in link records of the people removed (their address, and the IP address and browser that asked for each link), which are deleted on their own schedule, 30 days after each link expired (below). Two exceptions: an address we have put on our list of addresses we send no email to stays on that list; and if our email provider has reported that a notification email to an address of yours bounced permanently or was marked as spam, or that it had stopped sending to that address for another reason, such as an unsubscribe through the provider, we keep that address on our list of addresses we send no weekly summaries or change alerts to, until the provider reports that it is sending to that address again. We confirm when it is done.
Backups are deleted on a schedule. We back up the database that holds your data every night to storage that prevents any backup being deleted or altered for thirty days after it is written. That protection is locked: no one with access to our Azure account, including us, can delete or alter a backup in its first thirty days, or shorten or remove the protection. Each backup is deleted automatically about ninety days after it is written, and Azure keeps a deleted backup for about thirty days more before it is gone. So after we delete your data, copies remain in our backups for about four months at most, and they stay readable by us until then: a backup holds the workspace's wrapped data key along with its data, and our key in Azure Key Vault can still unwrap it. Azure encrypts the stored backups with keys Microsoft manages, which protects against theft of the storage media, not against someone who can reach the backups. One exception: the storage account our earlier pilot environment kept its backups in still exists and is not on this schedule, and any backup still in it stays until we delete it.
Sign-in links, sessions and other sign-in state have fixed retention periods, applied automatically:
- a sign-in link (and the IP address and browser that requested it) — deleted 30 days after it expires;
- a session (and its IP address and browser) — deleted 90 days after the session ended;
- the short-lived records used while signing in or connecting a tenant — deleted about a day after they expire (a tenant-connection request: 30 days after).
Our email log — the address, the kind of email and when, never the message or a sign-in link — has no fixed retention period. A workspace's entries are deleted with the workspace, and a sign-in email's entry with the account it belongs to. An entry for an address that never became an account is kept with no end date; ask us and we will delete it.
Our own copies of Monitor emails — weekly summaries and change alerts — are deleted by a daily job once they are more than 90 days old, counted from when they were queued, if they have been sent or given up on.
Our email provider, Postmark, keeps the messages it sent — the recipient, subject and body — for the period set by Postmark and our account with it.
Who else processes it
| Sub-processor | For | Where |
|---|---|---|
| Microsoft Azure | All hosting, storage, backups and key management | East US |
| Microsoft Graph, Defender for Endpoint, Exchange Online and, on the Monitor plan, Azure | The source of everything we read from your tenant and the subscriptions you choose | Your tenant's own region |
| Postmark | Our emails: sign-in links to anyone signing in; invitations to join a workspace, which carry the inviter's name or address, the workspace's name and the role offered, sent to the invited address; on the Free plan, a note when an assessment finishes, which carries finding counts only; and, for workspaces on the Monitor plan, change alerts and weekly summaries. A change alert carries your workspace's name and numbers only — how many new findings an assessment raised, or the date an assessment did not finish, and how many checks could not be read — never a finding's title or severity. A weekly summary carries your workspace's name; the titles, severities and counts of its findings; which areas could not be assessed; and findings set aside whose review date is near (the kind of decision and its date, not the reason typed for it). None of them carries evidence, or the names of people or devices we read from your tenant. | United States |
| Cloudflare (Turnstile) | A bot-detection check on the sign-in page, before we request a sign-in link. It runs only while the check is switched on. When it is on, your browser loads Cloudflare's script and widget from challenges.cloudflare.com. Cloudflare processes signals including your IP address, browser User-Agent and TLS fingerprint, the widget's site key and the associated origin, and returns a token. Cloudflare may use cookies as described in its Cookie Policy and Turnstile documentation. Our server sends the token and, when available, your IP address to Cloudflare for validation; it also sends the Turnstile credential needed to authenticate that request. We do not send Cloudflare the email address or company name entered on the page, or anything from your Microsoft tenant. Cloudflare acts as our processor when providing Turnstile and as a controller when it processes these signals to improve its own bot-detection capabilities, as described in its Turnstile Privacy Addendum. |
Cloudflare's global network; its Turnstile Privacy Addendum does not state a specific country or region. |
Prowler, which makes the Azure assessment, is not on this list because it is software we run on our own server, not a company processing your data for us.
No artificial-intelligence service processes your data in the product, and our rule is that none does in how we run and support it. Under that rule, in force since 28 September 2026, the people who run the service give AI tools no access to your Microsoft tenant or your workspace, and no administrative access to the server, database or backups that hold your data; and they use AI tools only with our own code, test data, public information, our own Microsoft tenants and workspaces, and output from our production systems that has been checked to carry none of your data before an AI tool sees it. The product contains a component that would ask a language model to check whether a finding is correct, and no model is deployed and it is not running. If it is enabled, it will run inside our own Azure subscription — not a third-party API — the prompt will carry the baseline policy, the finding and the evidence behind it, with email addresses, GUIDs, links, and domain names ending in .com, .net, .org, .gov, .edu, .io or .co.uk (that ending in lower case) replaced before they leave (other domain names, names of people, devices, groups and policies, and identifiers in other forms, are not removed), and no output of it will be shown to you or used to change a finding. We will update this notice before that changes.
What happens when you disconnect
Closing your workspace (an owner, in Settings) stops every assessment and email, signs everyone out, and stops our reading: nothing new is read from your tenant after it, though a read already under way can finish. Withdrawing admin consent in your tenant — by deleting our application under Enterprise applications in the Microsoft Entra admin center — stops Microsoft issuing us new access tokens; a token already issued keeps working until it expires, at a time Microsoft sets when it issues the token. In both cases the findings and evidence already collected remain in our database until deleted on request — see How long we keep it.
Your rights
Ask us for a copy of what we hold about you, correction of anything wrong, or deletion. Write to
support@defenssive.com. We will respond within thirty days.
Changes
We will tell you before this notice changes in a way that affects what we read, where it is processed, or who else processes it. Adding a Microsoft permission requires your administrator to approve the new set, so you will see it on Microsoft's own consent screen either way.
What this document asserts, and where to check it
For whoever maintains this. The main factual claims above, and what makes each one true — so that a change to the product that falsifies one is visible as a change to this list.
| Claim | Verifiable in |
|---|---|
| Every Graph permission is read-only | The app registration's requiredResourceAccess; each name ends .Read.*; GraphTokenBroker refuses a Graph token carrying anything else |
| The permission lists above are what the application requests: eleven Microsoft Graph, four Defender and two Exchange application permissions | The registration's requiredResourceAccess, read-only inventory of 2026-09-27 (docs/pilot-external-actions.md §3); scripts/create-entra-app.ps1 $APPLICATION and $DEFENDER_APPLICATION; GraphTokenBroker ExchangeRoles; ExchangeReader calls adminapi/beta; Microsoft Learn, Authentication and authorization for the Exchange Online Admin API (app-only flow: Exchange.ManageAsAppV2, calls to adminapi/v2.0; read 2026-09-28) |
| Every Defender permission is read-only; device actions are refused | GraphTokenBroker.DefenderRoles (exact allowlist of the four .Read.All roles) |
| Exchange use is read-only by role and by command list | ExchangeReader.Allowed (fixed Get- cmdlets, no parameters); AssessmentAccessReadOnlyCheck (High finding on a write-capable directory role); roles: Microsoft Learn, Microsoft Entra built-in roles permissions reference (Global Reader and Security Reader include microsoft.office365.serviceHealth/allEntities/allTasks and microsoft.azure.serviceHealth/allEntities/allTasks) |
| Teams use is read-only by role and by request list, with no Teams permission | TeamsReader.Allowed (four fixed GET paths, no query or body); GraphTokenBroker TeamsRoles (empty: a Teams token carrying any application role is refused); teams-probe on the owner's test tenant, 2026-10-10 (docs/go-live-readiness.md); Microsoft Learn, Application-based authentication in Teams PowerShell Module ("There's no need to configure any API permission for 'Skype and Teams Tenant Admin API'") |
| Azure is read only on the Monitor plan, only in subscriptions given the Reader role, with no Azure permission, by Prowler on our own server | CspmResultsFactory (not_entitled off Monitor: no Azure call); CspmJobRunner lists only the subscriptions Azure returns for the application and runs only enabled ones; GraphTokenBroker AzureRoles (empty: an Azure token carrying any application role is refused); KeyVaultAssertionSigner (assertions signed in Key Vault, five minutes), refreshed every four minutes by CspmJobRunner; infra/compose/cspm-runner.Dockerfile and docker-compose service cspm-runner (pinned Prowler 5.44.0 image digest, no database or Key Vault access); --excluded-services entra; Microsoft Learn, Azure built-in roles, Reader ("View all resources, but does not allow you to make any changes"); live runs on the owner's subscription 2026-10-10 (docs/go-live-readiness.md) |
| Evidence, assessment detail, Azure assessment results, sealed reports and queued weekly summaries are encrypted per workspace under a wrapped key; nothing else is | ADR 0009; constraints in 0051, 0052, 0125; report_snapshot 0143; cspm_run.results 0193 (CspmRunStore); audit_event.detail (0061) would be sealed, but nothing writes it; KeyWrapper (wrap and unwrap are calls to the vault); infra/azure/backup.sh header |
| One tenant cannot read another's rows | ADR 0002; db/tests/isolation.sql, run by CI on every push (.github/workflows/ci.yml, scripts/db-reset.sh) and by infra/azure/recovery-drill.sh against a restored backup; tables with a workspace column have row-level security enabled and forced, per the production catalogue read 2026-09-28 (docs/legal-corrections-proposed.md E15), except workspace_directory, which holds routing metadata only (migration 0002); of the tables without one, app_user, identity, email_event, email_suppression, notification_suppression and workspace have it enabled and forced (the same read) |
| No customer or user passwords anywhere | MagicLinkService, EntraAuthService; no password column exists |
| Withdrawing access stops new tokens; a token already issued is reused until 5 minutes before it expires and works until it expires; closing a workspace stops new reads | GraphTokenBroker: Cache, RenewBefore, the InvalidateConnection remarks; GetAsync re-reads the connection before every token; migration 0138 (closure disconnects; in-flight requests are not recalled); Microsoft Learn: Access tokens (its 60 to 90 minute default is stated for registered APIs, not Microsoft-owned APIs) |
| Data is in East US | DATA_REGION; the storage account and Key Vault are both East US |
| Closing a workspace stops assessments, email and new reads, and deletes nothing | Migration 0138, auth.close_workspace |
| Deletion on request removes the workspace's records, its data keys and the accounts of people in no other workspace from the live database; the purge record, both suppression lists and sign-in link records remain | Migration 0149, auth.purge_closed_workspace (suppression lists kept; magic_link_token not touched); migration 0150 (sign-in links reaped 30 days after expiry); docs/workspace-deletion.md |
| Backups: 30-day immutability (locked), deleted about 90 days after they are written, then about 30 days in soft delete; readable by us until gone; encrypted at rest by Azure with Microsoft-managed keys | infra/azure/backup-storage.sh; the lifecycle rule expire-database-backups on stdefenssiveprodbk (container database, prefix defenssive-); the container's locked immutability policy; the account's encryption keySource (Microsoft.Storage), each owner-run or read-only on 2026-09-28 (docs/pilot-external-actions.md §4); docs/workspace-deletion.md (each backup holds the wrapped keys); the earlier pilot environment's account stdefenssivepilotbk still exists, kept by the owner's decision of 2026-09-28; the 2026-09-28 rule and locks were applied to the production account, not to it (docs/counsel-fact-pack.md, docs/tenant-migration.md phase 6) |
| Sign-in record retention periods; the email log has none | Migration 0150, auth.reap_sign_in_state, run by AuthStateReaper (auth and link requests: expires_at more than 1 day past); email_message (0005) holds recipient, template and times, no body or link (EmailSender), and no reaper touches it: its rows go by cascade with a workspace, or in a purge for a removed account (0149) |
| Our own copies of Monitor emails deleted once sent or given up on and more than 90 days past queueing | Migrations 0125 (auth.reap_digest_outbox) and 0130 (auth.reap_alert_outbox): created_at < now() - interval '90 days', status sent or failed; run daily (ReapEvery, 24 hours) by DigestOutboxDispatcher and AlertOutboxDispatcher |
| Email delivery problems pause weekly summaries and change alerts only (off in production until the webhook is switched on) | Migration 0148, notification_suppression (read only by the digest and alert enqueues; auth.queue_email, used for sign-in links, invitations and the scan-finished note, reads email_suppression alone); PostmarkWebhook (ManualSuppression recorded as manual_suppression; Postmark's subscription change webhook documentation says an unsubscribe is reported as ManualSuppression, checked 2026-09-28); the endpoint answers 404 while POSTMARK_WEBHOOK_SECRET is unset, as it was in production on 2026-09-28 (docs/pilot-external-actions.md §2) |
| Postmark receives workspace names, finding counts and (weekly summaries only) finding titles and severities, never evidence | DigestContentModel (no external keys, no evidence), AlertTemplate, EmailTemplates.ScanFinished (counts only), EmailTemplates.Invitation (inviter, workspace name, role), PostmarkEmailProvider; migration 0130 header |
| Postmark keeps the messages it sent for its own retention period | docs/workspace-deletion.md; Postmark's documentation on message retention (checked 2026-09-27, docs/counsel-fact-pack.md); our account's setting is not recorded, so no period is stated |
| Turnstile is loaded only while the sign-in check is switched on. The application does not include the email address or company name entered on the page, or anything from a Microsoft tenant, in requests to Cloudflare. Browser-side signals processed by Cloudflare are described in its Turnstile Privacy Addendum. Server-side validation sends the Turnstile credential, widget token and, when available, the visitor's IP address. | TurnstileVerifier posts secret, response and, when known, remoteip, pinned by TurnstileVerifierTests; Turnstile.tsx loads Cloudflare's script only when GET /api/auth/config reports a site key; Cloudflare's Turnstile Privacy Addendum, dated 18 June 2025, describes the browser-side signals, purposes and processor/controller roles. |
| No AI processes customer data in the product; the operator rule for how we run it | UnavailableFindingReviewer is what is registered; no Foundry endpoint is configured; ReviewPrompt.Clean and IFindingReviewer Redactions (what the prompt would replace); the operator rule, decided 2026-09-28, how it is enforced, and its open items, docs/ai-tooling-rule.md |
Claims deliberately NOT made, because the product cannot support them yet:
- that data is deleted on disconnect or on closing — deletion is on request, by an operator;
- that a retention period applies to workspace data or to our email log — only sign-in links, sessions and other sign-in state, the current service's backups and our own copies of Monitor emails have one;
- that deleted data is gone from backups at once — copies remain in the current service's backups for about four months at most, and the earlier pilot environment's backups are not on that schedule;
- that a copy of our database or a backup is unreadable without our keys — only the fields listed under How it is protected are encrypted by us;
- that deleting a workspace's keys makes its backups unreadable — each backup holds its own copy of the wrapped key;
- that we are certified against any standard — no audit has been performed.