Privacy Policy
Effective Date: September 3, 2026
Publisher: Realizer Services Inc. | Contact: privacy@realizer.io
1. Introduction
This Privacy Policy describes how Realizer Services Inc. ("Realizer", "we", "us", "our") collects, uses, stores, and protects information in connection with AccessPoint, our access-to-information and privacy management solution for Microsoft 365 and Azure ("the App").
AccessPoint is designed with a data sovereignty model: customer data is stored and processed entirely within the customer's own Microsoft Azure subscription and Microsoft 365 tenant. Realizer does not host, store, or have standing access to customer data.
This policy covers three contexts:
- The Website — realizer.io and related pages
- The App — the AccessPoint software deployed in a customer's environment (the SharePoint web part, the Teams app, the API, the database, the storage account, and the optional Azure services the customer chooses to deploy alongside them)
- The Platform — Realizer's platform services that support licensing, Teams notifications, jurisdiction packs, first-time setup, Teams tab routing, and software distribution
2. Data Controller and Data Processor Roles
- Customer organizations are the data controller for all personal data processed within AccessPoint. They determine the purposes and means of processing personal data related to their access requests, privacy assessments, incidents, complaints, and risks.
- Realizer Services Inc. acts as a data processor only to the extent it processes limited data through the Platform (see Section 5). Realizer does not control or determine the purposes for which customer data is processed within AccessPoint.
- Microsoft is the customer's cloud provider. Every Azure resource AccessPoint uses — including the optional AI, search, speech, and security services in Section 4.6 — is provisioned in the customer's own subscription under the customer's own agreement with Microsoft. Realizer is not a party to that processing.
3. Information Collected via the Website
3.1 Information You Provide
We collect information that you voluntarily provide, including:
- Contact form submissions: name, email address, company, and message content
- Demo requests: name, work email, organization, the jurisdiction or regime you work under, and anything you tell us you would like to see
- Where submissions go: contact and demo submissions are emailed to Realizer and, for demo requests, recorded in our customer relationship system (HubSpot, hosted in North America) together with the page you first arrived on, the site that referred you, and any campaign parameters in the link you followed, so we know how you found us
- Service inquiries: information relevant to your onboarding or consulting needs
3.2 Automatically Collected Information
When you visit our website we use Google Analytics 4 to understand which pages are read and how visitors arrive. It records the pages you view and how long you stay, the site or search engine that referred you, your browser and device type, and an approximate location derived from your IP address; Google Analytics 4 does not log or store IP addresses. We have turned off Google signals and every advertising feature, so nothing is used for advertising and no profile is built across other websites. Visitors in the European Economic Area, the United Kingdom and Switzerland are asked before analytics cookies are set; elsewhere two first-party cookies (_ga and _ga_ followed by our property identifier) distinguish returning visitors. You can opt out on any device by opening any page of this site with ?ga=off added to the address, for example realizer.io/?ga=off, and ?ga=on turns it back on. The site sets no other tracking cookies.
4. Data Processed by the App (Customer Environment)
All of the following data is stored and processed exclusively within the customer's own Azure subscription and Microsoft 365 tenant. Realizer does not have access to this data.
4.1 User Identity Data
- Display name, email address, Entra ID object ID, and tenant ID
- Sourced from Microsoft Entra ID (Azure Active Directory) JWT tokens during authentication
- Used for authentication, authorization, audit logging, and people picker functionality
- Stored in the customer's Azure SQL database
- The web part keeps a 24-hour cache of the customer API's own address in the browser's local storage so it need not be rediscovered on every page load; the cache holds no user identifiers
4.2 Case Data
- Request details: titles, descriptions, request numbers, dates, statuses, priority levels, extensions, consultations, fees, hours, and correspondence logs
- Requestor information: names, contact details, addresses, organizational affiliations, preferred language, and requestor category — stored as reusable requestor contact records shared across a requestor's requests
- Requestor conduct records, where the customer chooses to record them: frivolous/vexatious determination details and notes, and an append-only conduct log attached to the requestor contact (removed when the contact is purged)
- Assignment and task records: custodian assignments, contributor tasks, instructions, due dates
- Attestation records: formal attestations with e-signatures
- Related case records, where the customer uses these modules: privacy incidents/breaches, complaints, privacy and algorithmic impact assessments, and risk register entries — including any personal data the customer records in them (e.g., individuals affected by an incident)
- Audit history: timestamped records of all create, update, and delete actions with user attribution, backed by a tamper-evident hash-chained audit ledger
4.3 Documents and Recordings
- Files uploaded by users (Office documents, PDFs, images, email files, and any other file type the customer's records contain), including records users capture from their own Microsoft 365 content (see Section 4.5)
- Video and audio records: the original recording is never modified; AccessPoint derives a playback proxy, poster image, scrub thumbnails, waveform, transcript, captions, and — at release time — a burned release copy, all stored beside the original in the customer's Blob Storage
- Converted PDF versions for preview and redaction, and a reduced-size viewer copy for very large PDFs
- Redaction records: the geometry, exemption citations, status, reviewer, and — for suggested redactions — the text the detector matched. Detected and overlay text is subject to the same access gate as requestor PII
- Redacted document versions and response packages (ZIP and merged PDF exports), together with a manifest of file hashes
- Plain text extracted from converted documents (including OCR of scanned documents when the optional Document Intelligence resource is deployed), spoken content transcribed from recordings (when the optional Speech resource is deployed), and on-screen text read from video frames (when Document Intelligence is deployed) — stored in the customer's Azure SQL database to power content search, duplicate detection, AI summaries, and redaction suggestions
- Working documents (Word, Excel, diagram, and list files edited in place), with their version history
- The malware scan verdict for each file when Microsoft Defender for Storage is deployed (Section 4.6.5)
- Stored in the customer's Azure Blob Storage with Microsoft-managed encryption at rest (customer-managed keys optionally available) and shared-key access disabled — every reader authenticates with an Entra identity
Email conversion. When an email file is converted for preview, the customer's API fetches remote images the message references (at most 25 images of up to 4 MB each, over an SSRF-hardened client with an 8-second timeout) so the rendered PDF matches what the recipient saw, then renders the page offline so that nothing — including tracking pixels — contacts the network during rendering. The image hosts named in the email therefore see a request from the customer's App Service at conversion time; no other party sees the message. Attachments are extracted into child documents by default (tenant toggle Features:ExtractEmailAttachments).
4.4 Configuration Data
- Tenant settings, notification templates, request types, choice fields, numbering configurations, jurisdiction pack content, custom fields, assessment templates, retention rules, and feature toggles
- Stored in the customer's Azure SQL database
4.5 Records Captured from Microsoft 365
The Documents workspace lets a signed-in user add records from their own Microsoft 365 content. Every capture is initiated by the user, gated by the tenant toggle Features:M365CaptureEnabled (with separate toggles for the request and assignment workspaces), and stored as an ordinary document in the customer's Blob Storage. Which identity performs the read matters for privacy, so each source is listed with its token:
| Source | What is captured | Token used | Notes |
|---|---|---|---|
| Outlook email ("My Email", shared/intake mailboxes) | Selected messages, downloaded as .eml files | The user's delegated token (Mail.Read, Mail.Read.Shared) | Exchange mailbox permissions still apply — a user sees only mailboxes they already hold access to |
| Outlook calendar | A date window of the user's own (or a shared) calendar, rendered as one day-grouped schedule record | The user's delegated token (Calendars.Read, Calendars.Read.Shared) | Items whose sensitivity is Private, Personal, or Confidential are excluded by default (opt-in). Attendees and location are included by default; descriptions and meeting join links are off by default. The record carries a banner noting the exclusion and that attendee names are third-party personal information subject to review |
| Teams chats and channel messages | The user's own chat and channel conversations, rendered as transcripts | The user's delegated token (Chat.Read, ChannelMessage.Read.All, Team.ReadBasic.All, Channel.ReadBasic.All) | Only conversations the user is a member of |
| OneNote | Pages from the user's notebooks | The user's delegated token (Notes.Read, Notes.Read.All) | |
| SharePoint lists and files | Lists rendered as records; files copied from sites and OneDrive | The user's delegated token (Sites.Read.All, Files.Read.All) | SharePoint permissions still apply |
| Teams meeting recordings and transcripts | Recordings of meetings the user organized, with the Teams-generated transcript | The user's delegated token (OnlineMeetingRecording.Read.All, OnlineMeetingTranscript.Read.All, OnlineMeetings.Read) | Graph lists recordings for the organizer only. The MP4 is downloaded through the user's browser into the upload queue and uploaded to the customer's API; the Teams WebVTT transcript is imported with it and is treated as authoritative — the recording is never re-transcribed. Nothing transits the publisher |
| Microsoft 365 Copilot interaction history | The user's own Copilot conversations, grouped by session, rendered as transcripts | The API's application permission (AiEnterpriseInteraction.Read.All) — there is no delegated permission for this data | Retrieval is performed server-side by the customer's API and is always scoped to the signed-in user's own Entra object ID, never tenant-wide. Requires the user to hold a Microsoft 365 Copilot licence. The permission is granted by default at setup with an opt-out |
Captured records are converted to PDF in the customer's App Service, stamped with their source (for example "Email Export", "Calendar Export", "Teams Meeting Recording", "Copilot Export"), and are indistinguishable from manual uploads thereafter.
4.6 Optional Azure Services
Customers may deploy the following services within their own Azure subscription by setting a deployment parameter. Each is provisioned by the same template as the rest of AccessPoint, in the customer's resource group, and each authenticates with the App Service's managed identity only — local authentication and API keys are disabled on every account that supports it (disableLocalAuth). None of them is required; an undeployed service simply leaves its feature unavailable. Document and case content processed by them does not leave the customer's Azure environment and is never sent to Realizer.
4.6.1 Azure OpenAI (AI Assist)
- Deployed by
deployAiAssist=true. Creates an Azure OpenAI account with a "chat" deployment (a mini-class model), an "embed" deployment for vectors, and — unlessaiPremiumDrafting=false— a "chat-premium" deployment used for letters, narratives, and the recall-sensitive redaction pass. - Data processed: case fields, document text, transcripts, and the user's question, composed into a grounding prompt for the requested feature (document summaries, suggested redactions, drafting, intake triage, custodian suggestions, assessment prefill, Ask AccessPoint, case check, risk suggestions, auto-tagging, fee-category suggestion, machine translation of customer-entered text, and vector embeddings for semantic search).
- Identity: the API's managed identity holds the Cognitive Services OpenAI User role; no key exists.
- Where processing runs: the account, its data at rest, and its endpoint stay in the region the customer chose. With the default Global standard deployment type, Microsoft may perform inference in other Microsoft regions; Data zone standard bounds inference to the EU or US data zone. The customer selects this at deployment (
aiDeploymentSku) and may pin the account's region (azureOpenAiLocation). Processing is subject to Microsoft's Azure OpenAI Service data, privacy, and security terms with the customer. - What is stored: the AI activity log (
AiAssistLog) records metadata only — feature, record identifier, model, prompt version, a hash of the prompt, token counts, duration, outcome, the initiating user, and the human accept/edit/dismiss decision. The composed prompt and the model's raw response are not persisted. Where a feature's output is something the user works with, it is stored as ordinary case data in the customer's SQL database: cached document summaries (per document and language), machine translations (stored per language and never overwriting a human translation), cached per-case artifacts (suggested next action, case check findings), suggested redactions (as proposals), and Ask AccessPoint conversation history (saved per user so a conversation can be resumed; the optional question-mining feature summarises themes across those conversations for administrators). - Human control: AI drafting outputs land in an editor for human review and are never sent automatically. AI-suggested redactions are recorded as proposals and are excluded from every export path until a human accepts them. Compliance-relevant findings in Case check are deterministic; the model may only add warnings and suggestions.
- Budget and opt-out: a monthly token budget (
Ai:MonthlyTokenBudget) stops all calls when exhausted. Every feature has its own toggle in Settings → Feature Toggles (Features:Ai*); the whole capability is removed by redeploying withdeployAiAssist=falseor deleting the account.
4.6.2 Azure AI Search (content and semantic search)
- Deployed by
deployAiSearch=true. - Data processed: an
accesspoint-documentsindex holding document metadata and the extracted text of each converted document (plus a vector when Azure OpenAI is also deployed), and anaccesspoint-casesindex holding vectors of request and assessment scope text for semantic duplicate detection, custodian suggestions, and prior-request retrieval. Results are always re-filtered against the caller's permitted document set, so a search can never surface a record the caller could not open. - Identity: the API's managed identity holds Search Index Data Contributor and Search Service Contributor; keys are disabled.
- Retention: index entries are written at upload and conversion, updated on re-conversion, and removed when the document or case is deleted or purged; orphaned entries are garbage-collected.
- Opt-out: without the resource, search falls back to metadata (name, type, tags). The semantic index additionally requires
Features:AiSemanticSearchEnabled.
4.6.3 Azure AI Document Intelligence (OCR)
- Deployed by
deployDocumentIntelligence=true. - Data processed: image-only PDFs (up to 300 pages per document) are sent page by page to the
prebuilt-readmodel and the recognised text is stored with the document; when the media features are used, sampled video frames (capped atRedaction:FrameScanMaxFrames, default 300) are read the same way so on-screen text can be searched and proposed for redaction. - Identity: the API's managed identity holds the Cognitive Services User role; keys are disabled.
- Region: Document Intelligence is hosted in a subset of Azure regions. When the customer's region does not offer it, the template places the account in the nearest supported region (for example Canada East → Canada Central) unless the customer overrides
documentIntelligenceLocation. Customers with strict regional requirements should confirm the resolved region. - Opt-out:
Features:OcrEnabled(documents) andFeatures:MediaFrameOcrEnabled(video frames) in Feature Toggles; or do not deploy the resource.
4.6.4 Azure AI Speech (transcription of recordings)
- Deployed by
deploySpeech=true. - Data processed: for each recording with an audio track, the API extracts a 16 kHz mono audio file into the customer's documents storage account and submits a batch transcription job. The Speech account reads that audio through its own system-assigned managed identity (Storage Blob Data Reader on the documents account) — no shared-access token is ever minted. When results are retrieved, the transcription job is deleted from the Speech service and the temporary audio file is deleted from storage. The transcript (with word timings), a caption file, and a plain-text rendering are stored with the recording.
- Identity: the API's managed identity holds Cognitive Services User and Cognitive Services Speech User; keys are disabled.
- Access to spoken content: transcript text is served only to users who hold the requestor-PII permission; other users see counts and timings only, and the captions track is unlocked by a separate token issued under the same gate.
- Teams transcripts: a recording captured with its Teams transcript is never sent to the Speech service.
- Opt-out:
Features:MediaTranscriptionEnabledin Feature Toggles; or do not deploy the resource.
4.6.5 Microsoft Defender for Storage (malware scanning)
- Deployed by
deployDefenderForStorage=true. - Data processed: Microsoft Defender for Cloud scans every blob written to the customer's documents storage account on upload and records a verdict as a blob index tag. AccessPoint reads only that verdict and mirrors it to the document record; a file flagged as malicious can never be previewed, played, downloaded, included, or released. Defender's separate sensitive data discovery feature is explicitly left off — AccessPoint classifies content itself.
- Scope: enabled on the documents storage account only, capped at
malwareScanCapGBPerMonth(default 5,000 GB) of scanning per month. - Opt-out: do not deploy the module; the app setting
Documents__MalwareScanningis then absent and verdicts read as "not scanned".
4.6.6 Media processing worker (Azure Container Apps)
- Deployed by
deployMediaProcessing=true. Without it, recordings are transcoded and burned in-process on the customer's App Service. - Data processed: the worker reads the original recording from the customer's storage account, produces the proxy, poster, thumbnails, waveform, and release renditions, converts very large Office documents, and writes the results back to the same storage account. It never connects to the customer's database or API — jobs and results travel through two Azure Storage Queues in the customer's subscription and carry blob paths, not content.
- Identity: the job's own managed identity holds Storage Blob Data Contributor and Storage Queue Data Contributor on the customer's accounts; the API's managed identity holds Storage Queue Data Contributor. The job scales to zero between bursts and each execution is a fresh process with a four-hour ceiling.
- Logging: the container environment writes its logs to the customer's own Log Analytics workspace.
- Container image: the worker is code, distributed like the API package. By default the job pulls
realizer.azurecr.io/accesspoint/media-worker:<version>anonymously from Realizer's container registry — see Section 5.6 for what the registry observes. For production, customers are recommended to mirror the image into their own Azure Container Registry (mediaWorkerImage+mediaWorkerRegistryResourceId), after which the job pulls with its managed identity and has no runtime dependency on Realizer. - In-tenant visual analysis: when a reviewer asks for it, AccessPoint can detect faces in sampled video frames and track a region a reviewer has drawn across the clip so the same blur or box follows it. Both run inside the customer's App Service with an open-source detector whose weights ship inside the application — no cloud vision service is called and nothing leaves the tenant. This is detection only: it proposes blur regions as proposed redactions for a human to accept; no facial template, identity, or match is computed or stored. Face detection is off unless the tenant enables
Features:MediaFaceDetectionEnabled. - Direct playback (optional): when the template is given the tenant's SharePoint origin (
sharePointOrigin), the browser streams recordings directly from the customer's storage account using a one-hour user-delegation token instead of proxying through the API.
4.6.7 Application Insights and Log Analytics (always deployed)
- Data processed: operational telemetry from the customer's API — HTTP method, path, status code, and duration of each request with a correlation ID; dependency calls to SQL, Blob Storage, Graph, and the optional services (duration and success/failure); unhandled exceptions with stack traces; document-conversion and media-processing timings; and the render-engine diagnostics used to confirm that email rendering is working. Telemetry may contain record identifiers and user identifiers needed to trace an operation; AccessPoint does not write document content, prompts, or requestor contact details into telemetry.
- Location and access: the Application Insights instance and Log Analytics workspace are in the customer's subscription; Realizer has no access to them. Metric alert rules are created only when the customer supplies an alert email address, which is stored in the customer's own Azure action group.
- Retention: 90 days by default (
logRetentionDaysin the monitoring module), adjustable by the customer.
4.7 Privacy by Design
AccessPoint enforces role-based data access:
- Custodians and Contributors never see requestor personally identifiable information (PII). They work from sanitized instructions.
- Notification templates for Custodian and Contributor roles automatically strip PII tokens before dispatch.
- Transcript text, detected redaction text, and overlay text are served only to users who hold the requestor-PII permission.
- Machine-produced redactions (pattern matches, rule-based suggestions, AI suggestions, face detection, duplicate propagation) are stored as proposals and are excluded from every burn, export, and redline path until a human accepts them.
- Administrators control which users have access to the system and at what role level; a senior official named on a case sees that case only.
- Tenant isolation is absolute. Every query in the customer's API is filtered by tenant, the filter is unconditional, and the API refuses any state-changing call whose token was issued by a different Entra tenant. No code path reads another tenant's data.
5. Data Processed by Realizer (Platform Services)
Realizer's Platform services process a limited set of data to support licensing, Teams notifications, jurisdiction packs, first-time setup, Teams tab routing, and software distribution. Email notifications, the in-app notification feed, documents, case records, AI prompts, and search indexes never transit Realizer.
5.1 License Validation
When the App starts and periodically during use, the customer's API sends a request to Realizer's Platform API (api.realizer.io) to validate the customer's subscription. While a licence is invalid the API backs off (five minutes, doubling) rather than polling continuously.
Data transmitted:
- Tenant ID (a Microsoft Entra ID identifier for the customer's organization)
- API version string (e.g., "2.1.0") for compatibility checking
- The customer API's own base URL (e.g.,
https://app-accesspoint-<name>.azurewebsites.net) — self-registered with the Platform so the SharePoint web part can discover the customer's API address without manual configuration (see Section 5.3)
The request authenticates with a Microsoft Entra token issued to the customer's App Service managed identity, which carries a License.Validate role on Realizer's application; the token's tenant claim identifies the customer. A legacy static API key remains supported as a fallback for un-migrated deployments.
Data NOT transmitted:
- No user names, email addresses, or personal data
- No request content, documents, or customer business data
- No usage counts, case counts, or feature-usage statistics
Purpose: To verify that the customer has an active AccessPoint subscription. The response also carries the latest published AccessPoint version number (and, optionally, a link to the update template) so the App can show administrators an "Update available" notice. Realizer's Platform determines that number by reading its own release marker (get.realizer.io/public/accesspoint/latest/version.txt); the customer's API does not contact the distribution site for this.
Data stored: one licence-token record per tenant and subscription (replaced on each validation; revoked records are retained as an audit trail), the tenant's subscription status, and the self-registered API base URL on the tenant record.
Retention: Tenant ID and license status are retained for the duration of the subscription plus 90 days after expiration for billing reconciliation. The self-registered API base URL is stored as part of the tenant's subscription record.
5.2 Teams Activity Feed Notifications
Teams activity feed notifications are optional and default to on. In the default mode, when a notification is triggered (e.g., a custodian is assigned new work), the customer's API sends a request to Realizer's Platform API, which sends the notification via Microsoft Graph on behalf of the customer's tenant. This relay exists because Graph requires that activity notifications be sent by the application that owns the Teams app manifest, and AccessPoint's Teams app is published under Realizer's multi-tenant application.
Data transmitted (default relay mode):
| Field | Contains | Personal data? |
|---|---|---|
tenantId | Customer tenant GUID | No — identifier |
recipientUserId | Recipient's Entra user object ID | No — identifier |
activityType | A fixed manifest value (e.g., assignmentCreated) | No |
previewText | Assignment or task name and due date | Potentially — free text |
topicText | The in-app notification text | Potentially — free text |
templateParameters.actorName | Display name of the staff member who triggered the notification | Yes — a personal name |
templateParameters.requestNumber | Request reference number (request-anchored types only) | No — reference |
relatedEntity, relatedRecordId | Record type and GUID for the click-through deep link | No — identifiers |
Data NOT transmitted:
- No requestor PII (names, contact details, addresses) — there is no requestor field in the payload, and Custodian/Contributor notifications are PII-blanked before dispatch regardless
- No document content
- No request details beyond the notification parameters listed above
Two controls reduce or eliminate this flow:
- Minimise — the tenant setting
Notifications:TeamsMinimalPayload(Settings → Setup → Teams Notifications → "Minimise Teams notification content") replacespreviewText,topicText, andactorNamewith fixed placeholders ("AccessPoint Notification", "You have a new AccessPoint notification", "AccessPoint"). No free text or personal name leaves the tenant; only routing identifiers do. - Direct relay — the app setting
Notifications:TeamsRelayMode=Directmakes the customer's API call Graph itself with its managed identity, so nothing reaches Realizer. It requires theTeamsActivity.Sendrole on the customer's managed identity and a Teams manifest pointed at the customer's own application (User Guide, Step 8e).
Turning Teams notifications off in the Setup panel also eliminates the flow; email and in-app delivery of the same notifications are always in-tenant.
Purpose: To deliver Teams activity feed notifications.
Data stored: none. The Platform logs the tenant and recipient identifiers of each relayed notification for troubleshooting.
Retention: Notification metadata is retained in transit logs for 30 days for troubleshooting purposes, then automatically deleted.
5.3 API Address Discovery
When the SharePoint web part loads and no manual API-address override is configured in the tenant, it calls the Platform's api-discovery endpoint to look up the customer API address that the licence validation self-registered (Section 5.1).
Data transmitted: a Microsoft Entra bearer token issued to the signed-in user for Realizer's application — the same token the web part uses to call the customer's own API. The Platform reads only the token's tenant claim to select the record; it does not store the token or the user's identity.
Data returned: the customer's own API base URL.
Data stored: none beyond the tenant record already described in Section 5.1. The Platform logs the tenant ID and whether a URL was found.
5.4 Teams Personal Tab Routing and First-Time Setup
Teams tab routing. The AccessPoint Teams app's personal tab opens through a Platform address (api.realizer.io/apps/accesspoint/redirect-to-sp) that decides whether the tenant has AccessPoint installed and redirects the user's browser to their own SharePoint site (or to a welcome page when it does not). This design is required by how Teams desktop establishes single sign-on with SharePoint.
- Data transmitted: the tenant's SharePoint domain (e.g.,
contoso.sharepoint.com), the tenant ID, and the user's locale — supplied by Teams as query parameters. No user identity, token, or content is sent. - Data stored: none. The Platform logs the three values for troubleshooting and answers with an HTTP redirect.
Finish Setup page. After a template deployment, an administrator may open the Platform's Finish Setup page (api.realizer.io/apps/accesspoint/setup) to grant the Microsoft Graph permissions the App's managed identity needs (Section 8.1), instead of running the deployment script.
- Data transmitted: the tenant ID and the managed identity's object ID (from the deployment output), and the administrator's choice of whether to include Copilot capture. The administrator signs in to a dedicated multi-tenant "AccessPoint Setup" application, and the page performs the grants with the administrator's delegated Graph token — Entra ID itself enforces that the administrator is entitled to make them; the page adds no privilege the administrator does not already hold.
- Data stored: none. The request context is carried in a sealed, tamper-proof state value valid for 15 minutes; the administrator's token is used for the duration of the request and is not retained.
5.5 Jurisdiction Packs
Jurisdiction packs (jurisdiction-specific templates, exemptions, holidays, notification templates, and detection rules) are downloaded from the Platform on request by an administrator. Each download and each installation report authenticates as in Section 5.1.
- Data transmitted: the tenant ID (via the token), the pack code requested, and — on installation — the list of item types installed and the Entra object ID of the installing administrator.
- Data stored: the installation record (tenant, pack, item types, installing user ID, timestamp), used to notify customers of pack updates.
5.6 Software Distribution
AccessPoint's installable artifacts are published to Realizer-operated endpoints. Fetching them reveals ordinary request metadata to Realizer — the artifact and version requested, the connecting IP address, and the time — and nothing else.
get.realizer.io— at deployment and upgrade time, the customer's Azure deployment downloads the API package for the requested version, and administrators download the deployment template, deployment script, and SharePoint package from the same site. There is no runtime dependency: the App does not contact this site while running.realizer.azurecr.io— when the optional media processing worker is deployed with the default image (Section 4.6.6), the customer's Container Apps job pulls the worker image anonymously each time it scales up from zero. The registry therefore observes the image tag, the egress IP address, the timestamp, and — because the job runs when there is media work — a pull cadence that approximates the tenant's media-processing bursts. It never observes content. Mirroring the image into the customer's own registry removes this flow entirely.
5.7 Summary — What Realizer Receives, and When
| Flow | When | What Realizer receives | Contains personal data? | How to eliminate |
|---|---|---|---|---|
| License validation | Startup and periodically | Tenant ID, API version, API base URL | No | Not applicable (required for licensing) |
| Teams activity relay | Each Teams notification (default mode) | Tenant and recipient GUIDs, activity type, request number, record ID; plus title, preview text, and acting user's name unless minimised | Acting user's name and free text unless minimised | Minimise toggle, Direct relay mode, or disable Teams notifications |
| API address discovery | Web part load (when no override and cache expired) | User's bearer token (tenant claim read; not stored) | Token only, transiently | Configure the manual AccessPoint_ApiUrl storage-entity override |
| Teams tab routing | Each time the Teams personal tab is opened | SharePoint domain, tenant ID, locale | No | Use AccessPoint from SharePoint rather than the Teams tab |
| Finish Setup page | Once per setup or upgrade, by an administrator | Tenant ID, managed identity ID, administrator's delegated token (transient) | Administrator identity, transiently | Use Deploy-AccessPoint.ps1 instead |
| Jurisdiction packs | On administrator request | Tenant ID, pack code, item types, installing user ID | Installing administrator's object ID | Do not import packs (universal baseline is imported automatically) |
| Artifact downloads | Deployment and upgrade | Version requested, IP address, time | No | Not applicable |
| Container image pull | Each media-worker scale-up (default image) | Image tag, IP address, time, pull cadence | No | Mirror the image into the customer's own registry |
| Email notifications | Never | — | — | — |
6. Data We Do NOT Collect
Realizer does not collect, store, or have access to:
- Access request content or details, assessments, incidents, complaints, or risks
- Requestor personal information (names, addresses, contact details)
- Documents, recordings, transcripts, redactions, or response packages
- AI prompts, AI outputs, search indexes, or AI activity logs
- User browsing behavior or device information (note: the customer's Application Insights instance collects operational telemetry within their own Azure subscription — Realizer does not have access to this data)
- Cookies or local storage identifiers
- Location data
- Usage statistics or feature-usage telemetry from the App
7. Data Storage and Security
7.1 Customer Data (App)
- Stored in the customer's Azure subscription (Azure SQL Database, Azure Blob Storage, and — when deployed — the optional Azure services described in Section 4.6)
- Encrypted at rest using Microsoft-managed encryption keys (customer-managed keys optionally available for Blob Storage)
- Encrypted in transit via TLS 1.3 (App Service) and TLS 1.2 or higher (Azure SQL, Blob Storage); the storage account accepts HTTPS only and blocks public blob access
- Access controlled by the customer's Entra ID and Azure RBAC policies; database access uses Entra-only authentication via managed identity (no SQL credentials exist), Blob Storage has shared-key access disabled, and every optional service disables local authentication — no key for any AccessPoint resource exists to be leaked
- Blob Storage keeps versions and soft-deletes for 30 days by default, so an accidental deletion is recoverable by the customer within that window and permanently removed after it
- Optional hardening at deployment: Microsoft Defender for SQL with vulnerability assessment (on by default; findings are stored in a dedicated storage account in the customer's subscription), Microsoft Defender for Storage malware scanning (Section 4.6.5), private virtual-network isolation of the database and storage (
deployNetworkIsolation), and a write-once evidence container with a time-based immutability policy (deployEvidenceWormContainer, default seven years) for exported evidence packages and redaction masters - Every write is recorded in the audit history and in a hash-chained audit ledger whose verification scheme is versioned so that historical chains remain verifiable
- Realizer has no standing access to customer Azure resources
7.2 Platform Data (Realizer)
- Hosted on Azure infrastructure in Canada
- Encrypted at rest and in transit
- Access restricted to authorized Realizer personnel with MFA-protected accounts
- No customer content or PII is stored on Realizer infrastructure
7.3 Website Data
- Contact form submissions are stored securely using Microsoft Azure infrastructure hosted in Canada
- Encrypted at rest and in transit
8. Third-Party Data Sharing
Realizer does not sell, rent, or share customer data with third parties.
The third-party services involved in data processing are:
8.1 Microsoft Graph API
AccessPoint reads and writes Microsoft 365 data through Microsoft Graph under three sets of permissions. All Graph calls are made from the customer's tenant (by the signed-in user's browser or by the customer's API) except the Teams activity relay described in Section 5.2.
Application permissions on the customer's App Service managed identity — granted by the administrator via the Finish Setup page or Deploy-AccessPoint.ps1; used by the customer's API without a signed-in user:
| Permission | Purpose | What is read or sent |
|---|---|---|
Mail.Send | Send notification emails from the configured shared mailbox | Notification content, from the customer's mailbox to the recipient — never via Realizer. Can be scoped to a mailbox group with an Exchange application access policy |
User.ReadBasic.All | Validate that the shared mailbox exists; resolve notification recipients | Basic profile fields (name, email) only; no mailbox contents |
TeamsAppInstallation.ReadForUser.All | Check whether the AccessPoint Teams app is installed for a recipient before sending a Teams notification | The recipient's installed-apps list, filtered to AccessPoint |
Application.Read.All | Teams setup validation — confirm Realizer's application is consented in the tenant | Service principal metadata; read-only |
AppCatalog.Read.All | Teams setup validation — confirm the AccessPoint Teams app is in the organization's catalog | Catalog metadata; read-only |
AiEnterpriseInteraction.Read.All | "Add from Microsoft 365 → Copilot" capture (Section 4.5) | The signed-in user's own Copilot interaction history — the API always scopes the call to that user's object ID. Granted by default; opt out at setup (-DisableCopilotCapture, or the Finish Setup checkbox) |
TeamsActivity.Send (optional) | Only when the customer adopts the Direct relay mode (Section 5.2) | Teams activity notifications sent by the customer's own identity |
The managed identity also holds the non-Graph License.Validate role on Realizer's application (Section 5.1).
Delegated permissions requested by the SharePoint package — approved by a SharePoint administrator; exercised in the signed-in user's browser with the user's own identity, so the user can never read more than they already can in Microsoft 365:
| Permission | Purpose |
|---|---|
User.Read.All | People picker, user search and resolution |
Sites.Read.All | SharePoint site browsing and Lists capture |
Files.Read.All | File browsing and capture from sites and OneDrive |
Mail.Read | Email capture and preview from the user's own mailbox |
Mail.Read.Shared | Email capture from shared and intake mailboxes the user already has access to |
Calendars.Read | Calendar capture (Section 4.5) |
Calendars.Read.Shared | Calendar capture from shared mailboxes |
Chat.Read | Teams chat capture |
ChannelMessage.Read.All | Teams channel message capture |
Team.ReadBasic.All, Channel.ReadBasic.All | Listing the user's teams and channels for capture |
Notes.Read, Notes.Read.All | OneNote capture |
OnlineMeetingRecording.Read.All | Listing and downloading recordings of meetings the user organized (Section 4.5) |
OnlineMeetingTranscript.Read.All | Downloading the Teams transcript of those meetings |
OnlineMeetings.Read | Reading the meeting metadata needed to list recordings |
access_as_user (Realizer's application) | The token audience for calls to the customer's own API and to the API address discovery endpoint (Section 5.3); not a Graph permission |
Realizer's multi-tenant application — consented by the customer's administrator; operated by Realizer for the Teams relay only:
| Permission | Purpose |
|---|---|
TeamsActivity.Send | Send Teams activity feed notifications on behalf of AccessPoint (Section 5.2). Cannot read Teams messages, channels, or any other tenant data |
AppCatalog.Read.All | Resolve the Teams app's catalog identifier so the notification carries the AccessPoint icon; read-only |
User.Read | Basic sign-in scope |
8.2 Realizer Platform API
Used to validate the subscription, relay Teams notifications, discover the API address, route the Teams tab, finish setup, and download jurisdiction packs — each described in Section 5 with the exact data transmitted.
8.3 Microsoft Azure (optional services)
Azure OpenAI, Azure AI Search, Azure AI Document Intelligence, Azure AI Speech, Microsoft Defender for Storage, Azure Container Apps, and Application Insights — when the customer chooses to deploy them, these are Azure resources inside the customer's own Azure subscription under the customer's agreement with Microsoft; document and case content processed by them does not leave the customer's Azure environment and is never sent to Realizer (see Section 4.6).
8.4 Other
No data is transmitted to any other third-party service. Syncfusion document conversion and PDF rendering libraries run entirely within the customer's App Service — no document content is sent externally. The Syncfusion PDF viewer loads JavaScript/CSS assets from cdn.syncfusion.com in the browser, but no document content is transmitted. The face-detection and region-tracking models used for video redaction ship inside the application and call no external service. The only other outbound connections the App makes are the email image fetches described in Section 4.3 and the artifact and image downloads described in Section 5.6.
9. Data Retention and Deletion
9.1 Customer Data
Data retention is fully controlled by the customer:
- Administrators configure a retention period per request type, assessment type, incident type, complaint type, and (for standalone risks) risk category. A type with no period keeps its records indefinitely — a tenant that configures nothing purges nothing.
- The built-in Retention Review lists expired records across all five registers, withholds any record still needed by an open case (an open linked request or complaint, or a live risk) with the reason shown, re-checks eligibility at the moment of purge, and deletes the record with every dependent row, document, converted PDF, rendition, search-index entry, and blob.
- A purge leaves only a retention purge log entry (record number, type, date) as evidence the record existed. That log is never itself purged.
- Requestor contacts can be anonymized or purged independently of their requests.
- Deleted blobs remain recoverable by the customer for 30 days under Blob Storage soft delete, then are permanently removed. Files in the optional write-once evidence container cannot be deleted before their immutability window elapses.
- AI activity log entries, audit history, and the audit ledger are retained until the customer removes them; they contain no document content.
- Deleting the Azure resources (SQL Database, Blob Storage, and any optional services) permanently destroys all data.
- Realizer cannot recover customer data after deletion, as it does not hold copies.
9.2 Platform Data
- License records: retained for the duration of the subscription plus 90 days.
- Notification transit logs and the operational request logs of the other Platform endpoints in Section 5 (tenant identifiers and request metadata, never content): retained for 30 days, then automatically deleted.
- Jurisdiction pack installation records: retained with the tenant's subscription record, on the same schedule as license records.
- No customer content is retained on the Platform.
9.3 Website Data
Contact form submissions and demo requests are retained for the duration of the business relationship. You may request deletion at any time.
10. Data Subject Rights
10.1 For End Users of the App
Requests related to personal data processed within AccessPoint (access, correction, deletion, portability) should be directed to the customer organization that deployed AccessPoint, as they are the data controller.
10.2 For Customer Organizations
As the data controller, customers can:
- Export every register — including requestor contacts, case activity, redaction schedules, and a complete inventory of stored documents with their storage paths and hashes — from Settings → Export, and copy the underlying files directly from their own storage account.
- Export or delete any data in their Azure SQL database and Blob Storage at any time.
- Use the Retention Review feature to manage data lifecycle.
- Decommission the entire environment by deleting their Azure resources.
10.3 For Website Visitors and Platform Data
You have the right to:
- Request access to your personal information
- Request correction or deletion of your data
- Withdraw consent for communications at any time
- Lodge a complaint with a data protection authority
To exercise these rights, or to request access to, correction of, or deletion of the limited data Realizer processes (tenant ID, license records, pack installation records), contact privacy@realizer.io.
11. International Data Transfers
- Customer data remains in the Azure region chosen by the customer during deployment. No cross-border transfer occurs unless the customer configures geo-redundant storage. Two optional services deserve attention: Azure OpenAI's default Global standard deployment type keeps data at rest in the customer's region but allows Microsoft to run inference in other Microsoft regions (choose Data zone standard to bound it to the EU or US data zone); and Azure AI Document Intelligence may be provisioned in the nearest supported region when the customer's region does not offer it (Section 4.6.3). The media processing worker, Speech, Search, Defender, and telemetry resources are provisioned in the customer's own region.
- Platform data (tenant ID, notification metadata, routing and setup metadata) is processed on Realizer's Azure infrastructure in Canada. Software artifacts and the container image are served from Realizer-operated distribution endpoints. Customers in the EU or other jurisdictions should ensure this is compatible with their data transfer requirements; the Direct relay mode (Section 5.2) and a mirrored container image (Section 4.6.6) remove the two recurring runtime flows.
- Website data is processed on Azure infrastructure in Canada.
12. Children's Privacy
AccessPoint is an enterprise business application. It is not directed at children and does not knowingly collect personal data from children under the age of 16.
13. Changes to This Policy
We may update this Privacy Policy from time to time. Material changes will be communicated through:
- An updated "Effective Date" at the top of this document
- A notice on the Realizer website
- Notification to active customers via email
14. Contact
For questions about this Privacy Policy or AccessPoint's data practices:
Realizer Services Inc. Email: privacy@realizer.io Website: realizer.io/privacy
15. Change History
- September 3, 2026 — Added a complete inventory of Microsoft Graph permissions (application, delegated, and Realizer's application) with the purpose of each; described every Microsoft 365 capture source and the token it uses, including the new Teams meeting recording and transcript capture; expanded the optional Azure services section to cover Azure OpenAI (including the premium deployment and deployment-type residency note), Azure AI Search, Document Intelligence OCR, Azure AI Speech transcription, Microsoft Defender for Storage, the Container Apps media worker and its container image, and Application Insights / Log Analytics, each with identity model, retention, logging, and opt-out; clarified what the AI activity log records and which AI outputs are stored as case data; documented the Teams relay field list and the two controls that minimise or eliminate it; added the API address discovery, Teams tab routing, Finish Setup, jurisdiction pack, and software distribution flows with a summary table of what Realizer receives; described in-tenant face detection and region tracking; updated the retention section for the five-register retention engine and the purge log; and added residency notes for the optional services.
- July 22, 2026 — Previous revision.