Security Flare — Privacy policy

Document version: v1 Last reviewed: 2026-06-26 Reviewed by: Security Flare leadership; pending external legal review.

This privacy policy describes how Security Flare ("we", "us", "Security Flare") handles personal information collected through the Security Flare service. It is published under the Australian Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles (APPs).

If you have a specific privacy question — including a request to access, correct, or erase personal information held about you — email hello@securityflare.com.au and we will respond within the timeframe required by the APPs (no more than 30 calendar days for access / correction requests).

1. Who this policy applies to

Security Flare is a multi-tenant SaaS that helps Australian Microsoft-centric Managed Service Providers (MSPs) and their customers reach and maintain ISO/IEC 27001:2022 certification. Three categories of people interact with the product:

The Microsoft Graph application-permission data we read (with each customer's explicit admin consent — see §3) is owned by the customer's Microsoft tenant. We act as a processor for it; the customer is the controller.

2. What we collect and why

2.1 Account + session data (we are the controller)

• Microsoft Entra ID profile fields — displayName, email, oid, tid. Collected during sign-in via the OIDC id_token. We use these to authenticate the user and bind them to their organisation row.
• Session metadata — IP address, user-agent, timestamps. Collected on every authenticated request and written to the Worker access log (Logpush → R2). Used for fraud / abuse detection and for the ISO 27001 A.8.15 audit trail.
• Audit-trail events (audit_log table). Each tenant write (clone a policy, mark a control, draft scope, etc.) writes a row including userId, organisationId, action, entityId, metadata blob, ipAddress, userAgent, createdAt. Surfaced to the tenant's org_admin at /audit-log.
• Operator audit-trail events. Same shape as tenant events but with userId = null and metadata.source = '<operator action>' so the forensic trail is unambiguous.

2.2 Customer compliance data (the customer is the controller)

• ISMS register content: ISMS scope statement (§4.3), interested parties (§4.2), objectives (§6.2), risks (§6.1), policies (A.5.1), controls status (A.5-A.8), assets (A.5.9), suppliers (A.5.19-A.5.23), incidents (A.5.24-A.5.27), audits + management reviews (§9.2-§9.3), findings (§10.1-§10.2), training records (A.6.3), documents (§7.5).
• Microsoft Graph evidence (with the customer's explicit application-permission admin consent — see §3). Examples include Conditional Access policy snapshots, Intune device inventories, sign-in audit logs, security alerts. Stored under R2 Object Lock with a 7-year retention.

Security Flare does not collect:

• Customer passwords (Microsoft Entra ID handles authentication end-to-end; we never see them)
• Payment card numbers (Stripe processes billing and we receive only the customer/subscription metadata — see §6)
• Marketing / behavioural-tracking identifiers
• Browser fingerprints

2.3 Billing data

Through Stripe (our payment processor) we receive:

• stripe_customer_id, stripe_subscription_id, subscription_status, subscription_plan, subscription_current_period_end. None of these carry payment-card data.
• Stripe is a sub-processor (see §7) and its privacy policy applies to the actual payment data.

3. Microsoft Graph application-permission consent

When a tenant admin clicks "Connect Microsoft Graph" inside Security Flare we redirect them to Microsoft's /adminconsent endpoint. They explicitly grant the listed permissions (read-only) before any Graph read happens. Permissions requested:

• Policy.Read.All
• Reports.Read.All
• Directory.Read.All
• SecurityEvents.Read.All
• IdentityRiskEvent.Read.All
• AuditLog.Read.All
• DeviceManagementConfiguration.Read.All
• DeviceManagementManagedDevices.Read.All
• RoleManagement.Read.Directory
• InformationProtectionPolicy.Read

Consent is revocable at any time from the customer's Microsoft Entra admin centre. Once revoked, Graph reads stop on the next scheduled run.

4. How long we keep it

Object-Lock-protected R2 prefixes (evidence/, policies/, exports/, logpush/) cannot be deleted by Security Flare staff during the lock period. This is intentional — it's what makes the audit trail tamper-evident. The tradeoff is documented in ADR-0014.

5. Where it lives

Customer data lives in Sydney (ap-southeast-2):

• Postgres — Neon, region pinned to ap-southeast-2.
• R2 (evidence, exports, Logpush, policies) — jurisdictional restriction set to AU / EU.
• Workers — Cloudflare Data Localisation Suite enabled so the request handler runs in-region.
• Cloudflare KV — used only for Graph token cache (encrypted with a Secrets Store key) and Entra JWKS cache. Region pinned via the Suite.

Data never leaves the region. See CLAUDE.md §7 for the operating principle and the whitepaper at docs/security-whitepaper.md for the verification details.

6. Who else sees it (sub-processors)

The full sub-processor list is published with our whitepaper at /trust. The current list (June 2026):

We do not engage additional sub-processors without updating this list in the public whitepaper.

7. Notifiable Data Breaches (Privacy Act Part IIIC)

Security Flare is bound by the Notifiable Data Breaches scheme. If we become aware of an unauthorised access to, or unauthorised disclosure of, personal information that is likely to result in serious harm to an individual we will:

1. Contain the breach immediately and assess scope.
2. Notify the Office of the Australian Information Commissioner (OAIC) and affected customers as soon as practicable, and in any event within 30 calendar days of becoming aware.
3. Provide the OAIC with the information specified in s 26WK of the Act (description, kinds of information involved, recommended steps for affected individuals).

We rehearse this annually as part of the RUNBOOK §5 incident drill.

8. Your rights under the Australian Privacy Principles

You have the following rights under the APPs (summarised; the Act and the OAIC guidance are authoritative):

• APP 12 — Access: request a copy of the personal information we hold about you. We will respond within 30 calendar days.
• APP 13 — Correction: request correction of inaccurate or outdated personal information. We will correct it or annotate the record within 30 calendar days.
• Complaint: lodge a complaint with us at hello@securityflare.com.au. If you are not satisfied with our response within 30 days you can escalate to the OAIC at www.oaic.gov.au.

Outside Australia, equivalent rights under your jurisdiction's law apply where the relationship is contracted; reach out and we will work with you in good faith.

9. Children's data

The Security Flare product is sold to MSPs and businesses. We do not collect personal information from people we know to be under 18. If you believe a minor has signed in, contact hello@securityflare.com.au and we will delete the account.

10. Cookies

Security Flare uses two first-party __Host- prefixed cookies:

• Session cookie (__Host-sf-session) — opaque session id pointing to a Durable Object. Secure, HttpOnly, SameSite=Lax. Required to stay signed in. Deleted on sign-out or session expiry.
• CSRF cookie (__Host-sf-csrf) — random token for double-submit protection on mutation requests. Same flags.

We use no third-party cookies and no advertising / tracking pixels.

11. Updates to this policy

We will publish an updated version of this policy at the same URL when material changes occur. The Document version + Last reviewed fields at the top of the page identify the current revision. Material changes will be summarised in the public changelog so a prospect can verify when (and how) the privacy posture has evolved.

12. Contact

Security Flare hello@securityflare.com.au Address available on request.

Privacy questions, APP 12/13 requests, and Notifiable Data Breach notifications can all be sent to the same address. We aim to respond within 5 business days even when the Act allows longer.