Technical Architecture

This document provides a technical overview of the AccessPoint platform for solution architects, cybersecurity engineers, and IT directors evaluating the product for their organization. It is drawn from the AccessPoint Solution Architecture Guide (v2.5.0).

Platform Overview

AccessPoint is an access-to-information and privacy management platform built on Microsoft 365 and Azure. It began as a subject access request (SAR) management tool and has grown into an integrated ATIP/privacy office suite covering the full request lifecycle and the surrounding privacy program. It runs entirely within your organization's own Microsoft 365 and Azure tenant: there are no external servers, databases, or third-party cloud dependencies at runtime, and all data remains in your environment under your control. Document conversion, viewing, editing and redaction burn-in run on AccessPoint's own document engine, inside your subscription.

The platform is organized into modules that share a single identity, RBAC, notification, audit, and reporting spine:

• Access requests — ATI/FOIA/GDPR intake, custodian tasking, document review and redaction, response packaging, and statutory reporting
• Video and audio records — recordings reviewed in the same document workspace: resumable uploads up to 50 GB, transcripts and captions, time-based redaction (box, blur, pixelate, mute, bleep, distort voice, withhold) with an exemption on every mark, in-tenant face detection and tracking, and burned MP4/MP3 release copies with a hash manifest
• Privacy assessments and audits — a configurable PIA/AIA/Security assessment engine with DPIA validation where a template configures it; privacy audits and regulator reviews run on the same engine
• Privacy incidents and breaches — intake, containment, risk-of-harm, and breach-notification workflows
• Complaints and appeals — complaint lifecycle with parties, statutory clocks, and investigation
• Privacy risk register — ISO 31000-style risks, treatment plans, and key risk indicators
• Privacy program — one hub for the inventory of programs, systems and vendors, GDPR Article 30 records of processing (ROPA) with register export, readiness by law, attestations and discovery surveys
• Commitments register — tracked privacy commitments with cadence and check-ins
• Public intake portal (optional) — an internet-facing web app for online requests, complaints and incident reports, status tracking, secure delivery of responses, a reading room and online fee payment through the institution's payment provider
• Repository connectors (optional) — browse, search and capture records from systems outside Microsoft 365 into any documents workspace, with provenance
• Accessible editions (optional) — accessible versions of response packages with a PDF/UA check
• Case archiving — storage policies that move closed cases' files to cooler storage tiers, preservation holds and a disposition log
• Train mode — a training copy of the tenant with fictional cases, guided learning, training paths and team exercises, kept apart from production
• AI Assist (optional) — Azure OpenAI-backed suggestions and drafting running entirely in the customer's own subscription: document summaries, AI redaction suggestions, grounded drafting, intake triage, assessment answer prefill, semantic search and duplicate detection, a statute-aware per-case assistant (Ask AccessPoint — clickable citations, saved conversations, a My-caseload mode), "Ask AccessPoint" data answers, a jurisdiction playbook that grounds process answers, auto-translation, and a daily brief — all opt-in per tenant, metadata-only logged, with per-record AI activity disclosure

All modules are jurisdiction-pack driven, with no static seed data.

Key characteristics:

• Tenant-native — deploys as a SharePoint Framework (SPFx) solution and Azure PaaS services within your existing tenant
• No Power Platform dependencies — no Dataverse, Power Automate, or Power Apps licensing required
• Data sovereignty — all data resides in your Azure tenant's configured geography
• No vendor runtime access — the publisher cannot access your data during normal operation
• Flat-rate licensing — priced by the covered population of the organizations whose records are processed, with unlimited users and no per-user metering; the AI Assist, public portal, media and repository connector modules are named in the signed license
• Own document engine — conversion, viewing, editing and redaction burn-in run on AccessPoint's own native document engine; a document worker in your subscription handles Office, HTML and e-mail conversion, and the viewer and editors are served from the API's own origin with nothing loaded from a CDN
• Shared services supported — one deployment can serve several Microsoft 365 tenants, each with its own license and its own data (see Several Organizations in One Deployment)
• Privacy by design — custodian and contributor roles are structurally walled off from requestor and data-subject PII
• Configuration over code — request types, exemption codes, and choice fields are data-driven
• Multilingual by design — a three-tier translation system supporting 11 languages
• Instants in UTC, calendar days in the user's zone — every timestamp is stored as a UTC instant, but statutory calendar facts (received date, due date, overdue, days remaining) are computed on the caller's local calendar from the time zone the web part sends with each request

Architecture Diagram

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌────────────────────────────────────────────┐
│                              │         │                                            │
│  SPFx Web Part               │         │  Azure App Service (Linux)                 │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API (TLS 1.3 min)     │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation              │
│   Teams Tab)                 │         │    ├─ Tenant guard + user upsert           │
│                              │         │    ├─ License + module checks              │
│  Installed from AppSource,   │         │    ├─ Permission-based authorization       │
│  the install page or the     │         │    ├─ PII filter middleware                │
│  Tenant App Catalog          │         │    └─ AccessPoint document engine          │
│                              │         │       (redaction burn-in, verification,    │
│  SharePoint Tenant Storage   │         │       viewer and editors; no CDN)          │
│  (API URL override,          │         │                                            │
│   optional)                  │         │  Azure SQL Database (application schema    │
└──────────────────────────────┘         │    and a separate portal schema)           │
                                         │  Azure Blob Storage + Storage Queues       │
        Microsoft Graph API              │  Key Vault (wraps the key ring)            │
        ┌──────────────────────┐         │  Application Insights + Log Analytics      │
        │ API identity (app):  │◄────────│                                            │
        │  Mail.Send           │         │  Container Apps environment (shared)       │
        │  User.ReadBasic.All  │         │   ├─ Document worker (default on):         │
        │  User.Read.All       │         │   │   Office / HTML / e-mail → PDF         │
        │  GroupMember.Read.All│         │   ├─ (opt-in) Media job                    │
        │  TeamsAppInstall…    │         │   └─ (opt-in) Accessibility checker job    │
        │  Application.Read.All│         │                                            │
        │  AppCatalog.Read.All │         │  (opt-in) Public portal web app            │
        │  AiEnterprise…Read   │         │           (+ optional Front Door + WAF)    │
        │ Signed-in user       │         │  (opt-in) Azure AI Search · Azure OpenAI   │
        │ (delegated): mail,   │         │           Document Intelligence · Speech   │
        │  calendar, files,    │         │  (opt-in) Defender for Storage             │
        │  Teams, OneNote, …   │         │  (opt-in) Relay (Hybrid Connections)       │
        └──────────────────────┘         └──────────────────┬─────────────────────────┘
          ← M365 record capture                             │ HTTPS + managed-identity token
            (delegated + app-only                           │ (API to connector only)
             Copilot)                    ┌──────────────────┴──────────────────────┐
                                         │  Repository connectors (optional)       │
                                         │   built-in: Azure Blob, MCP, SQL view,  │
                                         │     CMIS                                │
                                         │   remote, in Azure or on-premises       │
                                         │     through Hybrid Connections: file    │
                                         │     share, OnBase, OpenText Content     │
                                         │     Server (GCdocs), Laserfiche, Axon   │
                                         └─────────────────────────────────────────┘

Component Inventory

What the Publisher Operates

No customer data is transmitted to or stored by any publisher-operated service.

Functional Modules

All modules run inside the single Web API / SPFx web part and share one identity, RBAC, comment, notification, My Day, audit, hours, review-workflow, and reporting spine. Each is data-driven via Jurisdiction Packs.

Deployment Model

AccessPoint uses a split deployment model. The SPFx web part is installed into the tenant app catalog, the Teams app package is installed from AppSource or Teams Admin Center, and the Azure backend is deployed into the customer's own subscription by one of two methods:

• Guided Deploy to Azure form (recommended) — the Azure portal opens a four-page form (Basics, Features, Security and compliance, Advanced) that deploys the App Service, SQL, Blob Storage, Key Vault, the document worker and Application Insights, plus the optional public portal and Front Door, AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, Defender for Storage, media processing, accessibility checker, Hybrid Connections, private network and write-once evidence container options, via ARM/Bicep. The API package is deployed during the ARM deployment; code is downloaded once from the publisher CDN and stored in the customer's App Service, with no runtime external dependency. A required installation type choice guards redeploys: New installation creates the SQL server Entra-first (the deploying principal becomes the initial Entra admin, Entra-only auth from birth, so no SQL credential ever exists), while Upgrade existing installation preserves operator app settings, keeps customer-managed encryption keys and leaves database access untouched. The customer retains full ownership of the resource group.
• Bicep template + PowerShell script — for organizations with strict change control. Deploy-AccessPoint.ps1 deploys the infrastructure, re-asserts SQL Entra-only authentication, grants Microsoft Graph permissions to the managed identity (the scripted alternative to the Finish Setup page), configures the optional API-URL override and approves SPFx API permission requests. Each step can be skipped independently.

Graph permissions are normally granted through the publisher's Finish Setup page — the deployment emits a finishSetupUrl output that a customer Entra administrator opens to grant every managed-identity permission in one idempotent pass (re-run after upgrades to pick up new permissions). The SharePoint package is installed from the browser through an install page linked from the deployment's outputs: the administrator signs in to Microsoft 365, the page checks Realizer's signature on the package, and the administrator's browser installs it into the tenant app catalog with the administrator's own SharePoint rights. No package file is downloaded or uploaded by hand, and the Microsoft sign-in never leaves the administrator's browser. Later SharePoint package updates come from Settings > Setup > Update now through the same verified path.

Signed releases. Every release folder carries a SHA256SUMS manifest, detached signatures of the manifest and of every artifact, the publisher's public key and CycloneDX software bills of materials. A version folder is written once and never overwritten, and a version reaches the customer channel only through a manual approval plus evidence gates (functional tests, a penetration test, a performance run, a security review, a bug review and release notes). Signatures carry no transparency-log entry, so verification works offline. The deployment script verifies automatically, and its strict mode refuses unsigned material and installs exactly the verified packages.

The deployment is security-hardened by default: TLS 1.3, FTPS disabled, SCM/FTP basic authentication disabled, HTTP/2 enabled, Microsoft Defender for SQL on by default (opt-out), and a Key Vault wrapping the data-protection keys. Optional hardening includes a private network (service endpoints or private endpoints with public access turned off), Front Door with a web application firewall in front of the portal and the API, Defender for App Service, Defender for Storage malware scanning, a write-once evidence container, and customer-managed encryption keys for the documents storage account and the database. The API bundles its database DacPac and applies it on startup via a migration service (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false), so schema changes are additive and non-destructive; the outcome is surfaced through /api/health. Post-deployment, an administrator grants consent for the Realizer enterprise app (Teams notifications), configures the sender mailbox, and imports a jurisdiction pack.

Authentication and Identity

AccessPoint uses Microsoft Entra ID as its sole identity provider. There are no application-specific user accounts or passwords. The SPFx web part acquires a JWT for the API audience via AadHttpClient; the API validates the issuer, audience, signature, and expiry on every request. MFA and Conditional Access policies configured in the tenant apply in full.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│

Managed Identity

The App Service uses a system-assigned managed identity to authenticate to backend services, so no client secrets or certificates are stored in the application:

• Azure SQL Database — Entra-only authentication (the server is created Entra-first; no SQL credential ever exists)
• Azure Blob Storage — DefaultAzureCredential (managed identity in production)
• Microsoft Graph API — ManagedIdentityCredential with application permissions
• Azure Key Vault — the API identity may only wrap and unwrap with the one dataprotection key, through a role assigned on the key rather than the vault
• Optional resources (AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, the workers' Storage Queues) — managed-identity-only, with local/key auth disabled; the Speech account, the document worker, the media job, the accessibility job and the public portal each carry their own managed identity scoped to the containers, queues and schema they need (the workers never reach SQL or the API), and a customer-mirrored worker image is pulled with the worker's identity through an AcrPull grant
• Microsoft 365 in a different Entra tenant — the template attaches a second, user-assigned identity, and the API signs in to Microsoft 365 as a multitenant app registration that trusts that identity as a federated credential. No client secret exists and no license key is needed

Managed identity credentials are rotated automatically by Azure.

Authorization and RBAC

AccessPoint implements a granular, tenant-configurable permission model stored in Azure SQL and enforced at the API layer on every request: a product-defined catalog of atomic permission codes (e.g. request.modify, document.view, redaction.approve, request.view.pii) is grouped into roles, and every controller action is gated on a permission code.

Enforcement points:

1. [RequirePermission(code)] attributes — a dynamic policy provider maps each controller action to a catalog permission code
2. PermissionService — resolves the caller's effective permissions (standing roles unioned with per-target relationship grants), with object-scoped checks at request/document/assignment/task level
3. Resource-level ownership checks — e.g., a Contributor can only access their own tasks; a Custodian only their own assignments
4. PiiFilterMiddleware — strips requestor PII fields from JSON responses for any caller who does not hold the view-requestor-PII permission

All API write endpoints enforce permissions server-side at the controller level. Document reclassification is scope-aware — the user who collected a document is the one who can reclassify it — and once a request is closed, mutations on its object graph return HTTP 409, with a small set of deliberate exceptions (post-closure correspondence, retention purge, and reopen). Standing role assignments are scoped (global, request, assignment, or task), optionally time-limited, and relationship roles are never written as standing assignments — they are derived per-target from the underlying work records. The first user to access the system is bootstrapped with the Administrator role, and a server-side guard prevents removing the last active Administrator.

Data Residency and Sovereignty

All data resides in the customer's Azure tenant in the region selected during deployment. No data is transmitted to or stored in other regions unless the customer explicitly configures Azure geo-replication.

Canadian federal departments: For GC-specific data-residency requirements, ITSG-33 control mapping, and GC Cloud Guardrails compliance, see the GC Security Controls Reference.

Customer Data Locations

What Crosses Tenant Boundaries

What Never Leaves the Tenant

• Request records and requestor PII
• Uploaded documents, recordings, transcripts, and released copies
• Audit history
• Configuration data (request types, templates, numbering)
• Role assignments
• Document conversion and media processing — all of it runs in the customer's App Service or Container Apps; the only outbound request a conversion makes is the download of an e-mail's remote images (at most 25 per message, public addresses only)
• Repository connector traffic, and everything the public portal holds — the publisher hosts nothing for the portal, and the portal never calls the publisher
• AI Assist prompts and responses — when AI Assist is deployed, the Azure OpenAI resource runs in the customer's own subscription and region; Microsoft does not train models on the content, and prompt/response content is not stored (only usage metadata, for the budget meter and the case audit export's AI-involvement disclosure)
• In-app and email/Outlook notifications — the in-app feed is served from the customer's own API; email is sent from the customer's own shared mailbox via Mail.Send. Neither transits the publisher. Only the optional Teams activity feed sends any data outside the tenant, and even that can be minimised or eliminated (below)

Teams Notification Data Sharing (Optional)

Consistent with the data-sovereignty promise, the only tenant data that leaves the boundary for notifications is an optional Teams activity payload — and it can be minimised or removed entirely. Every notification is delivered on up to three channels; two are always in-tenant (the in-app feed, served from the customer's API, and email/Outlook, sent from the customer's own shared mailbox). The Teams activity feed is a convenience: in its default mode the customer API POSTs a small payload to the publisher's multi-tenant app, which calls Graph sendActivityNotification (which must be invoked by the app that owns the Teams manifest). The publisher stores none of it and logs only the recipient + tenant GUIDs.

Fields in the default (publisher-relay) Teams payload — and what the Minimise toggle strips:

Requestor PII is never in the payload — there is no requestor name/email field, and Custodian/Contributor notifications are PII-blanked upstream regardless. Two controls tighten this further:

• Minimise (Notifications:TeamsMinimalPayload, a tenant toggle) replaces previewText, topicText, and actorName with neutral placeholders, so names, titles, and free text never leave the tenant — only routing/deep-link identifiers do. No manifest change required.
• Eliminate (Notifications:TeamsRelayMode=Direct) makes the customer API call Graph sendActivityNotification itself with its managed identity, so no payload reaches the publisher at all. It requires the TeamsActivity.Send app-role on the API's managed identity and the Teams manifest's webApplicationInfo.id pointed at the customer's own app — see the Deployment Guide.

Several Organizations in One Deployment

By default each customer deploys its own instance: a dedicated database, App Service and storage account, with the tenant ID from each user's validated token scoping every query. A deployment that serves one organization behaves exactly like that, and nothing below applies to it.

Since 2.5.0, one deployment — one set of Azure resources and one database — can also serve several Microsoft 365 tenants. This is the pattern for a shared-services team serving the departments of a government, or a provider serving client organizations.

• Shared services, separate data. Each served tenant keeps its own users, roles, settings, jurisdiction packs, cases, documents, training copy and license. Every record carries its tenant, an unconditional query filter scopes every read to the caller's tenant, and blob paths are prefixed with the tenant ID. The compute, database, storage, workers, AI and portal are shared, so they are sized for all tenants together.
• Each tenant on its own license. The deployment validates each tenant's license with a token issued in that tenant, so every organization needs its own subscription. An additional tenant is served only while its own license is valid and only while the Azure operator lists it.
• The list is an operator setting. The additional tenants are an App Service setting that only someone with Azure access to the App Service can change. No AccessPoint administrator of any tenant can add one.
• One Microsoft 365 identity per tenant. The deployment signs in to each tenant through the federated multitenant app registration, which exists in a tenant only once that tenant's administrator has consented it. That consent is the authorization. Email, Teams notices, directory search, group-based roles and Copilot capture all run in the tenant's own directory with its own identity, and never fall back to another tenant's connection.
• A tenant that is not ready fails alone. Until its administrator has consented the app, or while its license is missing or expired, its users are refused and nothing is written for them. The readiness check names each served tenant whose license or Microsoft 365 connection is not working.
• Each tenant installs its own front end. The SharePoint package, the Teams app and the notification mailbox live in the tenant's own Microsoft 365, and the web part finds the shared deployment's API by itself.

Network and Firewall

AccessPoint needs no custom ports and opens no inbound path into your own network. Every connection uses HTTPS on port 443, except the database connection (TDS on port 1433) between your web apps and your Azure SQL server. Staff reach AccessPoint through SharePoint and Teams; the only public-facing surface is the optional public portal.

Arrows start on the side that opens the connection, which is the side a firewall rule has to allow. Dashed boxes are opt-in. The virtual network and its subnets exist only when network isolation is chosen at deployment (see Network Isolation Options); without it, the same services use public endpoints protected by Entra-only authentication, OAuth-only storage with shared keys disabled, and no anonymous blob access.

Inbound Connections

No pipeline or Realizer system connects to your Azure SQL database: the API applies the schema itself at startup, and the server accepts Entra authentication only. Realizer has no access to your Azure resources, database or files.

Outbound Connections from the Deployment

If a firewall or proxy controls the deployment's outbound traffic, allow these destinations. Opt-in rows are needed only when that component is deployed or that feature is turned on.

Staff and Requester Browsers

If a web proxy or filter sits in front of staff devices, these destinations must be reachable over HTTPS 443, alongside SharePoint Online and Teams themselves:

Requesters' browsers (opt-in portal) reach the portal's host, the payment provider's hosted page, and *.blob.core.windows.net for secure-delivery downloads: single-file, read-only links that bypass Front Door. Under network isolation the portal streams the file itself instead.

On-Premises Records Systems

Repository connectors reach records systems on your premises, such as network file shares, Hyland OnBase and OpenText Content Server, through Azure Relay Hybrid Connections. The Hybrid Connection Manager, installed on a host in your network, connects out to Azure Relay (*.servicebus.windows.net) on port 443 and forwards the tunnelled traffic to the configured host:port. No inbound firewall rule and no VPN are needed. The API calls connectors with its managed-identity token; browsers never call a connector, and Realizer never sees connector traffic.

Network Isolation Options

By default the template deploys public endpoints protected by Entra-only authentication, OAuth-only storage with shared keys disabled, and no anonymous blob access. The template also offers a private network, best chosen at initial deployment because a Container Apps environment cannot join a virtual network after it is created:

Beyond the template, you can add inbound private endpoints for the API and portal web apps, Network Security Groups on the integration subnets, and a SQL firewall restricted to the App Service's outbound addresses (network isolation already restricts it to the virtual network). Front Door, WAF, App Service and blob logs go to your Log Analytics workspace by default; send a copy to a SIEM or Event Hubs with diagnostic settings of your own.

What Is Reachable from the Internet

• The public portal (opt-in) is the only public-facing surface. Its JSON routes send no CORS headers and require a custom header on every change, so only its own pages can call them; the payment notification endpoint is the only route a third party posts to.
• The API is publicly routable, or reachable only through Front Door with frontDoorForApi, but every call needs an Entra ID token, cross-origin calls are accepted only from SharePoint Online, and its host name appears on no public page. The portal never calls it: the two exchange work through tables in the database.
• Rate limits apply per user (1,200 requests a minute by default) and per address for anonymous calls, with HTTP 429 and Retry-After when exceeded.
• The workers have no inbound endpoint at all; they take their work from storage queues.

Encryption

In Transit

The App Service enforces TLS 1.3 as its minimum at the front door (TLS 1.0/1.1/1.2 rejected); outbound connections to Azure backend services negotiate TLS 1.2 or higher.

At Rest

Application-Level

Privacy by Design

AccessPoint implements structural privacy controls that are enforced at the API layer, not only in the UI.

PII Filter Middleware

A response-level middleware intercepts all JSON responses and strips PII fields for any caller who does not hold the view-requestor-PII permission (Custodians, Contributors, Readers, Reviewers, and Advisors never hold it), server-side, regardless of what the client requests. Fields stripped: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, plus representative identity/contact fields and identity-verification notes.

Notification PII Blanking

When notifications are sent to Custodians or Contributors, requestor PII is replaced with placeholder text in the notification content itself — even if the notification template includes PII merge fields.

Custodian / Contributor Isolation

• Custodians see only their assigned requests and work from sanitized instructions
• Contributors see only their assigned tasks
• Neither role can search, browse, or access requests outside their scope

Logging, Monitoring, and Audit

Application Insights

All API telemetry is sent to the customer's Application Insights instance:

Audit Trail

AccessPoint maintains a comprehensive audit trail in the AuditHistory table (Azure SQL), recording the entity type, entity ID, action (Create, Update, Delete, StatusChange), field name, old/new values, an optional change reason (captured on status transitions such as close and reopen), the authenticated user, and a UTC timestamp. Audit records are immutable — they cannot be modified or deleted through the API.

Hash-Chained Audit Ledger

In addition to the field-level audit trail, a tamper-evident, append-only AuditLedger (SHA-256 hash chain) records actions across all modules. Integrity can be verified server-side, and a court-ready case audit export (formerly "evidence package") can be generated for a request.

Optimistic Concurrency

High-contention entities (Requests, Documents, CustodianAssignments) each carry a SQL Server ROWVERSION concurrency token. The client echoes the row version on update; if another writer has changed the row in the interim, the save is rejected with HTTP 409 ("Concurrent edit detected") rather than silently overwriting.

Retention Purge Log

One RetentionService engine disposes of aged-out records across five registers — requests, assessments, incidents, complaints, and standalone privacy risks — driven by a per-type RetentionPeriodMonths + RetentionStartPoint (NULL = keep indefinitely, the default). Records that must not age out are excluded by construction (an In Effect assessment, an Accepted risk, a risk anchored to a case), and an expired record another open case still depends on is refused server-side; eligibility is re-evaluated at purge time. When a record is purged the engine deletes document blobs, converted PDFs, annotations, and export packages from Blob Storage in addition to the database records. The RetentionPurgeLog records what was deleted, when, and by whom — EntityName identifies which register it came from, alongside a snapshot of its number, type, close date, and document count — a compliance-grade trail that survives the data removal and is itself never purged.

Log Analytics and Alerts

Application Insights is backed by a Log Analytics workspace with configurable retention (default 90 days; configurable 30–730 days). Data can be exported to Microsoft Sentinel or an existing SIEM. The Bicep deployment includes two default metric alerts on the App Service:

When an alert email address is supplied at deployment, scheduled-query alerts for SQL authentication failures, media job failures, and a media queue stall are created alongside them. Customers can customize thresholds and add action groups (email, SMS, webhook) in the Azure Portal.

Resource logs for the API and portal web apps, the Front Door profile (when deployed) and the documents storage account's blob operations, as well as the Key Vault audit log, are sent to the same workspace by default. When an alert address is supplied, a further alert rule fires on any mismatch or write failure of the audit-ledger anchors.

Related Pages

• Deployment Guide — deploy and update AccessPoint, optional components, signed releases.
• GC Security Controls Reference — ITSG-33 control mapping.
• GC Privacy Impact Assessment — data flows and privacy analysis.
• Security Controls — the security controls AccessPoint applies.