Technical architecture overview for IT teams evaluating AccessPoint

Last updated: July 12, 2026 by Steve

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 (v1.4.1).

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.

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
  • Privacy assessments — a configurable PIA/AIA/Security assessment 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
  • Records of processing (ROPA) — GDPR Article 30 records and register export
  • Commitments register — tracked privacy commitments with cadence and check-ins

All modules are configuration-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 — departmental licensing with no per-user metering
  • 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

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               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Component Inventory

Component Technology Deployed To Purpose
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 Customer SharePoint Online / Teams User interface for all roles
Teams App Teams manifest v1.19, app version 1.0.0 Customer Teams Admin Center Personal app, configurable tab, activity feed notifications with deep linking
Web API C# / ASP.NET Core 10, .NET 10 (~87 controllers, ~88 services) Customer Azure App Service (Linux) Business logic, data access, document processing
Database SQL Server (DacPac) Customer Azure SQL Database Relational data store (~186 tables, ~2,900 fields)
Blob Storage Azure Blob Storage Customer Azure Storage Account Document file storage
Monitoring Application Insights + Log Analytics Customer Azure Subscription Telemetry, diagnostics, alerting
AI Search (opt-in) Azure AI Search Customer Azure Subscription Full-text document content search; provisioned only when deployAiSearch=true

What the Publisher Operates

Service Purpose
Realizer Platform License key issuance and validation (no customer data transmitted)
AppSource Listing SPFx package distribution
Azure Marketplace Listing Azure infrastructure deployment template
Teams App Package Teams manifest distribution (sideload or org app store)

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 Configuration Packs.

Module Summary
Requests (ATIP/SAR) Request intake → custodian tasking → collection → response. Configurable types, statuses, numbering, calendars, and SLAs.
Documents & Redaction Faceted document workspace: tags, email families, read tracking, saved views, Syncfusion preview, redaction pipeline with exemptions and XFDF round-trip, response packaging.
Requestors / Contacts First-class reusable requestor identity, intake flow control, fees & verification, merge; consultations; correspondence composer with PII firewall.
Privacy Assessments Configurable PIA/AIA/Security engine: templates, screeners, section delegation, scoring/tiering, risk register, closure/regulator summaries.
Privacy Incidents / Breach Incident intake, containment, risk-of-harm, breach-notification rules by regime, remediation.
Complaints & Appeals Complaint lifecycle: parties, statutory clocks, admissibility, investigation, representations review.
Risk & Commitments ISO 31000 risk register with appetite, KRIs, and treatment tasks; commitments register with cadence and check-ins.
ROPA / Privacy Subjects Reusable programs/systems with GDPR Article 30 records and register export.
Reviews Configurable sequential/parallel review-and-approval engine reused across all case entities.
Reporting & Audit Fixed reports, custom report builder, statistical annual reports, SLA/management dashboards, hash-chained audit ledger and court-ready evidence packages.
Configuration & Platform Configuration-pack import, tenant settings, custom roles/permissions, feature toggles, custom fields, 11-language translation tables.

Deployment Model

AccessPoint uses a split deployment model. The SPFx web part is installed from Microsoft AppSource (or a tenant App Catalog), the Teams app package is installed via sideloading or the organization's app store, and the Azure backend is deployed into the customer's own subscription by one of two methods:

  • Azure portal (recommended) — one-click deployment of all Azure resources (App Service, SQL, Blob Storage, Application Insights) via ARM/Bicep. The API is deployed by zipdeploy 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. The customer retains full ownership of the resource group.
  • Bicep template + PowerShell script (manual) — for organizations with strict change control. A Deploy to Azure button or Deploy-AccessPoint.ps1 deploys the infrastructure, configures SQL Entra-only authentication, grants Microsoft Graph permissions to the managed identity, configures SharePoint tenant storage entities, and approves SPFx API permission requests. Each step can be skipped independently.

The deployment is security-hardened by default: TLS 1.3, FTPS disabled, SCM/FTP basic authentication disabled, and HTTP/2 enabled. The API bundles its database DacPac and applies it on startup via a migration service using DacServices.Deploy(upgradeExisting: true) — a no-op on an already-current schema, and an additive, non-destructive delta after a schema change (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). The migration 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-specific configuration 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. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Parameter Value
Identity Provider Microsoft Entra ID (Azure AD)
Protocol OAuth 2.0 / OpenID Connect
Token Type JWT Bearer
Audience api://<client-id> and <client-id> (both v1 and v2 tokens accepted)
Issuer https://login.microsoftonline.com/{tenantId}/v2.0 and https://sts.windows.net/{tenantId}/
App Registration Single-tenant (AzureADMyOrg); exposed scope access_as_user; no client secret

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 (SQL password authentication is disabled)
  • Azure Blob Storage — DefaultAzureCredential (managed identity in production)
  • Microsoft Graph API — ManagedIdentityCredential with application permissions

Managed identity credentials are rotated automatically by Azure.

Authorization and RBAC

AccessPoint implements application-level role-based access control stored in Azure SQL and enforced at the API layer on every request.

Role Sees Requestor PII Manages Requests Manages Assignments Submits Documents Typical User
Administrator Yes Config only No No IT admin, system owner
SAO Yes Yes Yes No Access & privacy officer
Reviewer Yes Read only Read only No Legal counsel, QA
Custodian No No Own assignments No Department records officer
Contributor No No No Own tasks Subject matter expert
Reader No Read only Read only No Oversight, audit

Enforcement points:

  1. API authorization policies — ASP.NET Core [Authorize(Policy = "...")] attributes on every controller action
  2. RoleAuthorizationHandler — checks the UserRoles table for the authenticated user's role membership
  3. ResourceOwnerAuthorizationHandler — validates resource-level ownership (e.g., a Contributor can only access their own tasks)
  4. PiiFilterMiddleware — strips requestor PII fields from JSON responses for restricted roles (Custodian, Contributor, Reader)

All API write endpoints enforce roles 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). Roles are scoped and can be constrained to specific resources (global, request, assignment, or task scope). The first user to access the system is bootstrapped with both the Administrator and SAO roles.

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

Data Type Storage Location Controlled By
Request records, user data, audit trail Azure SQL Database Customer's Azure subscription
Uploaded documents Azure Blob Storage Customer's Azure subscription
Application telemetry Application Insights / Log Analytics Customer's Azure subscription
SPFx web part assets SharePoint CDN Customer's M365 tenant
Tenant configuration (API URL, Client ID) SharePoint Tenant Storage Entities Customer's M365 tenant

What Crosses Tenant Boundaries

Data Flow Direction What Is Transmitted Purpose
License validation API → Publisher Platform License key (opaque string), tenant ID Validate active subscription
Email notifications API → Microsoft Graph Email content via Mail.Send Send notifications from shared mailbox
Teams notifications API → Publisher Platform → Microsoft Graph Activity type, preview text, recipient ID, template parameters Send Teams activity feed notifications (proxied through the publisher's multi-tenant enterprise app because sendActivityNotification must be called by the app that owns the Teams manifest)
User profile lookup SPFx → Microsoft Graph User search queries People picker, user resolution

What Never Leaves the Tenant

  • Request records and requestor PII
  • Uploaded documents
  • Audit history
  • Configuration data (request types, templates, numbering)
  • Role assignments

Encryption

In Transit

Connection Protocol Minimum TLS
Browser → App Service HTTPS (enforced, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (enforced by SharePoint context) TLS 1.3
App Service → Azure SQL TDS with encryption (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (managed identity) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

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

Data Store Encryption Key Management
Azure SQL Database Transparent Data Encryption (TDE) Microsoft-managed keys (default) or customer-managed keys (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Microsoft-managed keys (default) or customer-managed keys (CMK)
Application Insights Platform encryption Microsoft-managed keys

Application-Level

Feature Mechanism
Document viewer tokens ASP.NET Core Data Protection (WOPI-style token, 15-minute TTL, tenant cross-check on every anonymous viewer call)
Attestation e-signatures SHA-256 hash of signatory and timestamp stored in audit fields

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 users holding restricted roles (Custodian, Contributor, Reader), server-side, regardless of what the client requests. Fields stripped: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

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:

Signal What Is Captured
Request traces HTTP method, path, status code, duration, correlation ID
Dependency tracking SQL queries, Blob operations, Graph API calls (duration, success/failure)
Exceptions Unhandled exceptions with stack traces
Custom metrics Request processing times, document conversion durations

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 evidence package can be exported 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

When records are purged under retention policy, the purge deletes document blobs, converted PDFs, annotations, and export packages from Blob Storage in addition to the database records. The RetentionPurgeLog table records what was deleted, when, and by whom — a compliance-grade trail that survives the data removal.

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:

Alert Severity Condition Window
Server Errors 2 (Warning) HTTP 5xx count > 5 5 minutes
High Latency 3 (Informational) Average response time > 5 seconds 15 minutes

Customers can customize thresholds and add action groups (email, SMS, webhook) in the Azure Portal.

←
Previous Getting Started with AccessPoint
Next GC Security Controls Reference
→