Security & architecture
This page is written so a security reviewer can complete most of a vendor assessment without emailing us.
It documents the actual architecture, the actual Microsoft Graph permissions Checkpoint requests and when, the engineering controls in place, how the AI features are governed, and how to report a vulnerability. Nothing here is aspirational marketing copy — where something isn't finished yet, it says so.
Architecture
Checkpoint has no backend and no database of its own. There is nowhere for your data to go except the Microsoft 365 tenant it already lives in — compare that to the typical third-party GRC platform, where your risk register and audit findings are copied into someone else's cloud.
How Checkpoint works
Every arrow stays inside the boundary. Checkpoint reads and writes Microsoft Graph and SharePoint as you, the signed-in user — nothing is copied out.
The typical third-party GRC platform
Your risk register, audit findings and control gaps get copied out to the vendor's own database — subject to their breach-notification process, not yours. Not how we work.
Checkpoint permissions
Consent is staged, not bulk. Sign-in only ever asks for the read-only permissions in Stage 1 below. Every write-capable permission is requested separately, the first time — and only the first time — the feature that needs it is actually used. An administrator consents to each stage explicitly.
| Permission | Access | Purpose |
|---|---|---|
User.Read | Read | Your own basic profile — who is signed in |
Directory.Read.All | Read | Admin/guest counts, OAuth app consent list, Checkpoint role-group lookup |
Policy.Read.All | Read | Conditional Access policies — MFA coverage, legacy-auth checks |
SecurityEvents.Read.All | Read | Microsoft Secure Score |
DeviceManagementManagedDevices.Read.All | Read | Intune device compliance state |
DeviceManagementConfiguration.Read.All | Read | Whether Intune compliance policies exist |
RoleManagement.Read.Directory | Read | Whether privileged roles use PIM (time-bound) or standing access |
IdentityRiskyUser.Read.All | Read | Risky sign-ins / risky users (Entra ID P2 — skipped gracefully without it) |
| Permission | Access | Purpose |
|---|---|---|
Sites.Manage.All | Read / Write | Creates and maintains the SharePoint lists that back every Checkpoint register — risks, actions, evidence, vendors, policies, audits |
| Permission | Access | Purpose |
|---|---|---|
Mail.Send | Write (send) | Sends email as you, the signed-in user — never a service account |
| Permission | Access | Purpose |
|---|---|---|
cognitiveservices.azure.com/.default | Read (inference call) | Bearer token for your own Azure OpenAI resource, in your own tenant — access is Entra RBAC, never an API key |
All of the above are delegated permissions — Checkpoint acts as the signed-in user's own account, with their own consented token. There is no application (app-only) permission, no service account, and no admin-consent-only grant anywhere in the interactive app.
Two features outside the core app have their own, separate permission footprints, and are excluded from the claim above by design:
User.Read and Sites.Read.All — against the partner's own tenant, never a client's.Engineering controls
No CDN dependencies, no inline scripts, no unsafe-eval. Every event is bound via addEventListener and delegated data-action attributes — never onclick="" — so an injected inline script has nowhere to execute.
default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self' data:; connect-src 'self' https://graph.microsoft.com https://login.microsoftonline.com https://*.openai.azure.com https://*.cognitiveservices.azure.com; object-src 'none'; base-uri 'self'
The Azure OpenAI connect-src entries allow a connection only to whichever resource you provisioned in your tenant — never a Compliance365-hosted endpoint.
Every script Checkpoint ships is content-hashed at build time and served with a matching SRI integrity attribute — if a byte changes anywhere in the delivery path, the browser refuses to run it. The version number is injected from a single source of truth and verified before release, so a build can never silently ship stale or mismatched code.
Checkpoint is a static web app. It has no server to breach and no database to exfiltrate, because neither exists. Every register is a SharePoint list; every scan reads Microsoft Graph directly from your browser, signed in as you. Off-boarding costs you nothing — the data was always yours.
Every material action — a control status change, a risk approval, an AI request, a permission stage granted — is written to an append-only audit log stored in your own tenant. It's a record you own and can inspect, not a log sitting in our infrastructure.
AI transparency
Checkpoint's AI drafts policy language, evidence descriptions, risk treatment notes and questionnaire answers — grounded in your own registers, never invented. It has no tool or function calling, so it cannot take an action on its own; every response is text plus one line that never changes:
"AI-assisted draft — review before use."
It runs on your own Azure OpenAI resource, provisioned in your tenant and reached with your own Entra ID token — no API key, ever sent to us, and no Compliance365-hosted endpoint in the loop.
The governance rails
What we don't collect
No customer data in our database — because we don't operate one for Checkpoint. Every register lives in your SharePoint.
No API keys, ever stored or transmitted. Azure OpenAI access is your own Entra token, requested fresh each time.
No credentials of any kind. Sign-in is Microsoft's own identity platform (MSAL) — we never see, request or store a password.
No server-side logs of your tenant content. There's no server in the request path to log it on.
No advertising or cross-site tracking cookies on this marketing site, and none inside Checkpoint at all.
No reselling or sharing of data with any third party, for any purpose, under any circumstance.
This marketing website — not Checkpoint, which runs no analytics at all — uses three tools, honestly accounted for:
Full cookie-by-cookie detail, including exact names and expiry periods, is on the cookie policy page.
Found a problem?
We don't run a paid bug bounty programme. We do take reports seriously, and we won't come after a good-faith researcher who follows this policy.
/checkpoint/) and its demo instanceGood-faith research conducted within this scope, without accessing, modifying or exfiltrating data beyond what's needed to demonstrate the issue, will not result in legal action from us. Stop and report as soon as you've confirmed impact — don't go further than necessary.
Email info@compliance365.com.au with a description, reproduction steps, and any relevant proof of concept. Encrypt if you'd like — ask and we'll provide a key.
We ask for 90 days from your report before any public disclosure, or a timeline we agree together — whichever is sooner is fine by us, but talk to us first.
This policy is also published machine-readably at /.well-known/security.txt.
Send it to your security or procurement contact's usual channel, or straight to us.
Hi! I’m the Compliance365 AI. I can help you work out which security or privacy framework you need, explain what’s involved, and answer questions about ISO 27001, SOC 2, Essential Eight, and more.
What can I help you with today?
Messages are sent to our AI assistant (Claude, by Anthropic) to generate a reply — not stored as part of your account and not used to train AI models.
