Security

1. The shortest version

• We only request read-only Microsoft Graph and Azure Cost Management permissions.
• Customer data is stored in EU data centres (Frankfurt and Copenhagen) and never leaves the EEA without Standard Contractual Clauses.
• All traffic is TLS 1.2+; data at rest is encrypted with AES-256.
• Tenant credentials are OAuth refresh tokens, encrypted with a per-tenant key. We never see your users' passwords.
• You can revoke our access at any time from your Entra tenant — we lose access immediately.

2. Microsoft 365 tenant access

When you connect a tenant, you grant us delegated, read-only access via either Microsoft admin consent or a manual app registration. Both paths grant the same scope:

• Directory.Read.All — list users, groups, departments and licensed assignments.
• Organization.Read.All — read organisation information and license inventory.
• AuditLog.Read.All — read sign-in activity for idle-account detection.
• Reports.Read.All — read aggregate usage and consumption reports.

We do not request any write or directory-modify scopes. The application registration in your Entra tenant is auditable in the standard Enterprise applications blade and can be revoked there at any time. Revocation takes effect on the next API call we make.

3. Credentials and secrets

We store the minimum required to call Microsoft Graph on your behalf:

• Express setup — a refresh token issued by Microsoft after admin consent. Encrypted at rest with a per-tenant key derived from a hardware KMS.
• Manual setup — your application (client) ID, tenant ID, and either a client secret or certificate thumbprint. Secrets and private keys are encrypted at rest with AES-256; the encryption key is not co-located with the encrypted blob.

Secrets are never logged, never returned in API responses, and are decrypted only inside the sync worker that talks to Microsoft Graph. We will email the workspace owner 30 days before a stored client secret expires so you can rotate it without downtime.

4. Data location and residency

Customer data — tenant inventory, usage figures, report definitions, recipient lists and delivery events — is stored exclusively in EU data centres. Database primary is in Frankfurt; encrypted backups are replicated to Copenhagen. We do not transfer customer data to non-EEA jurisdictions for routine processing.

Where a sub-processor occasionally requires transfer outside the EEA (for example, for support tooling under our control), we rely on Standard Contractual Clauses and the additional safeguards required by GDPR. The current list of named sub-processors is included with our Data Processing Agreement.

5. Encryption

• In transit — TLS 1.2+ between all clients, our edge, and every backend service. HSTS is set on every customer-facing host.
• At rest — AES-256 for database volumes, object storage and backups. Tenant secrets are additionally encrypted with a per-tenant key before being persisted.
• Recipient magic links — signed with Ed25519, audience-scoped, and expire after 30 days.

6. Access control

Production access is restricted to a small number of named engineers and is granted on a need-to-know basis through short-lived, MFA-protected sessions. Routine operations (deploys, log inspection, on-call investigation) are performed through audited tooling — no engineer holds standing database credentials. All production actions are logged.

Inside the application, role-based access control separates workspace owners, admins, and reports-only users. Recipient magic links are scoped to a single report and a single recipient cohort; recipients are never enrolled into our authentication system.

7. Application security

• Dependencies are tracked and updated continuously; we run automated SCA on every push.
• Secrets are managed by a centralised secret store; none are committed to source control.
• Static analysis and type-checking run on every pull request. CSP, X-Frame- Options, and Referrer-Policy headers are set at the edge.
• Sensitive endpoints are rate-limited and protected against CSRF using same-site cookies and per-action tokens.

8. Operational security

• Backups are taken daily, encrypted, and tested by quarterly restore drills.
• Application and audit logs are retained for 365 days in the EU. Logs are scrubbed of credentials and personal data where it is not strictly required for diagnostics.
• We monitor availability, error rate and Microsoft Graph quota usage in real time; on-call engineers are paged on anomalies.

9. Incident response

We maintain a written incident response plan. Confirmed security incidents affecting customer data are communicated to the workspace owner within 72 hours of confirmation, in line with GDPR Art. 33, with follow-up post-mortems published as soon as the situation is contained. To report a suspected vulnerability, write to security@365.report. We respond within one business day and credit reporters who request it.

10. Compliance and audits

365.report is operated in line with GDPR, the Danish Data Protection Act, and the obligations Microsoft requires of Graph applications that handle tenant data. SOC 2 Type II audit is planned for late 2026; the readiness work is underway. A Data Processing Agreement (DPA) and our list of named sub-processors are available on request from legal@365.report.

11. Customer responsibilities

Security is shared. To get the most out of these controls, we recommend that you:

• Use Microsoft Entra Conditional Access for the admin who grants consent — at minimum, MFA.
• Limit workspace owner and admin roles in 365.report to the people who genuinely need them.
• Rotate manually-managed client secrets at least every 24 months. We'll remind you 30 days before expiry.
• Review the recipient list on every report — magic links are powerful and should go only where they are intended.

12. Contact

Security questions, DPA requests, or vulnerability reports: security@365.report.
Privacy questions: privacy@365.report.
Everything else: hello@365.report.

Applikeable, CVR 46168437, Copenhagen, Denmark.