ITSG-33 control mapping, GC Cloud Guardrails compliance, and SA&A reference for Canadian federal government departments
Last updated: August 06, 2026 by Steve
GC Security Controls Reference
This page is for Canadian federal government departments conducting a Security Assessment and Authorization (SA&A) for AccessPoint. It maps AccessPoint's security controls to the ITSG-33 framework, GC Cloud Guardrails, and related TBS/CCCS requirements.
For the full technical architecture, see the Technical Architecture page.
Architecture Summary for Assessors
AccessPoint runs entirely within the department's own Microsoft 365 and Azure tenant. The security-relevant facts underpinning the mappings below are:
- Backend — an ASP.NET Core Web API on Azure App Service (Linux), Azure SQL Database, and Azure Blob Storage, all deployed into the department's own Azure subscription.
- Identity — Microsoft Entra ID is the sole identity provider (JWT bearer tokens). The App Service authenticates to backend services with a system-assigned managed identity; Azure SQL is created Entra-first with Entra-only authentication — no SQL credential ever exists, so there is nothing to store, rotate, or disable.
- Access control — granular, permission-based access control enforced server-side on every API endpoint: a product-defined catalog of atomic permission codes is grouped into tenant-configurable roles, and PII-filter middleware strips requestor PII from responses for any caller not holding the view-requestor-PII permission.
- Encryption — TLS 1.3 at the App Service front door (TLS 1.2+ on Azure SQL and Blob Storage); TDE on the database and AES-256 SSE on Blob Storage at rest.
- Audit — an immutable field-level audit trail plus a hash-chained (SHA-256), append-only audit ledger with court-ready per-request case audit exports (formerly "evidence packages"); an opt-in WORM (write-once) blob container can make them immutable at the storage layer. Telemetry in Application Insights / Log Analytics with default metric alert rules, and Microsoft Defender for SQL enabled by default.
- Publisher boundary — license validation authenticates with an Entra managed-identity token (the token's tenant ID claim identifies the tenant) and transmits only the tenant ID, API version, and the API's own base URL; the response also carries the latest published AccessPoint version so the Setup panel can show an "Update available" notice (version numbers only — no usage or case data). No customer case data is transmitted to or stored by the publisher. The single optional egress is the Teams activity-feed notification payload (routing GUIDs plus, by default, the notification title/preview and acting-user name — never requestor PII), relayed through the publisher's multi-tenant app because Graph requires the manifest-owning app to send it. A department can minimise it (a toggle strips names and free text, leaving only routing identifiers) or eliminate it entirely (self-host the relay so nothing reaches the publisher); email and the in-app feed carry the same notices in-tenant. See Teams Notification Data Sharing.
GC Security Framework Alignment
| Framework | How AccessPoint Aligns |
|---|---|
| ITSG-33 (PBMM profile) | Security controls mapped to all ITSG-33 families. See the ITSG-33 Control Family Mapping below. |
| GC Cloud Guardrails | All 13 mandatory guardrails addressed. See the GC Cloud Guardrails Compliance table. |
| Policy on Government Security | System designed for formal SA&A. The authorization boundary is defined in the Authorization Boundary section below. |
| Directive on Security Management | Audit trail, access control, and continuous-monitoring capabilities support ongoing compliance. |
| Directive on Service and Digital | Cloud-native architecture aligned with the GC cloud-first directive. Deploys entirely within the department's existing M365 and Azure tenant. |
| CCCS Cloud Security Risk Management | Shared responsibility documented. Azure Canadian regions are CCCS-assessed for PBMM. |
Canadian Data Residency
For Government of Canada deployments, AccessPoint is deployed to Canadian Azure regions (Canada Central or Canada East). All data — including request records, uploaded documents, audit trails, and telemetry — resides within the selected Canadian region. No data is transmitted to or stored in regions outside Canada unless the department explicitly configures Azure geo-replication to do so.
Microsoft Azure's Canadian regions have been assessed by the Canadian Centre for Cyber Security (CCCS) and are approved for PBMM (Protected B, Medium Integrity, Medium Availability) workloads.
What PBMM Means for AccessPoint
- Protected B — AccessPoint handles requestor PII (name, email, phone, address) and potentially sensitive government records. The application's PII-filter middleware, role-based access control, and encryption controls are designed for Protected B data.
- Medium Integrity — All data modifications are captured in an immutable audit trail, reinforced by a hash-chained audit ledger. Database constraints and API-level validation protect against unauthorized modification.
- Medium Availability — The application is stateless, with all state in Azure SQL and Blob Storage. Azure platform SLAs and customer-configurable redundancy support medium-availability requirements.
ITSG-33 Control Family Mapping
The table below maps each ITSG-33 control family to the relevant sections of the Technical Architecture page. Use this as a starting point when evaluating AccessPoint against your department's PBMM security control profile.
| ITSG-33 Family | Control Area | Where Addressed |
|---|---|---|
| AC — Access Control | Authentication, authorization, least privilege, server-side RBAC, PII filtering, session management | Authentication and Identity, Authorization and RBAC, Privacy by Design |
| AU — Audit and Accountability | Logging, immutable audit trail, hash-chained ledger, monitoring, log retention | Logging, Monitoring, and Audit |
| CA — Security Assessment and Authorization | SA&A process, system boundary, continuous monitoring | Authorization Boundary (this page); Platform Overview; continuous monitoring via Logging, Monitoring, and Audit |
| CM — Configuration Management | Baseline configuration, change control, hardening defaults | Deployment Model (hardening defaults, additive DacPac migrations) |
| CP — Contingency Planning | Backup, disaster recovery, business continuity | Stateless App Service (all state in Azure SQL and Blob Storage); Azure-managed SQL backups and Blob redundancy configured by the department — see Deployment Model |
| IA — Identification and Authentication | Entra ID identity provider, MFA, managed identity, Entra-only SQL auth | Authentication and Identity |
| IR — Incident Response | Incident handling, notification, reporting to CCCS | Immutable audit trail, hash-chained ledger, and Log Analytics support investigation — see Logging, Monitoring, and Audit. Departments report cyber events to CCCS per GC requirements. |
| MP — Media Protection | Data-at-rest encryption, media sanitization | Encryption, Data Residency and Sovereignty |
| PE — Physical and Environmental Protection | Physical security of infrastructure | Azure CSP responsibility — covered by Microsoft's CCCS assessment for PBMM |
| PL — Planning | Security plans, system authorization boundary | Platform Overview; Authorization Boundary (this page) |
| RA — Risk Assessment | Threat/risk assessment, vulnerability scanning | Department-conducted VAPT and TRA (see Key Documents to Request); Azure platform scanning by Microsoft |
| SA — System and Services Acquisition | Supply chain, third-party dependencies, vendor practices | Component Inventory, What the Publisher Operates; full dependency inventory available on request |
| SC — System and Communications Protection | Encryption in transit, tenant isolation, boundary protection | Encryption, Data Residency and Sovereignty. Single-tenant deployment with dedicated resources; departments can add Private Endpoints, VNet integration, and WAF. |
| SI — System and Information Integrity | Patching, vulnerability management, input integrity | Deployment Model (hardening defaults, additive migrations). OS/runtime patched by Azure; application code and dependencies patched by the publisher. |
GC Cloud Guardrails Compliance
The following table maps AccessPoint's controls to the GC Cloud Guardrails — the mandatory minimum security configurations for GC cloud adoption.
| Guardrail | How AccessPoint Addresses It |
|---|---|
| 01 — Protect root/global admin accounts | AccessPoint does not use or require Global Admin accounts at runtime. Admin roles within the application are separate from Azure/M365 admin roles. Initial deployment requires admin permissions; ongoing operation does not. |
| 02 — Management of administrative privileges | Granular, permission-based access control enforced server-side at the API layer on every request: atomic permission codes grouped into roles, with Administrator the only built-in role (a server-side guard prevents removing the last active Administrator). Operational roles are tenant-configurable and separate from Administrator, and role assignments can be time-limited. The App Service authenticates via a system-assigned managed identity with no stored credentials, and Azure SQL is created Entra-first with Entra-only authentication (no SQL credential ever exists). See Authorization and RBAC. |
| 03 — Cloud console access | AccessPoint does not access the Azure Portal or any cloud management console at runtime. Azure resource management remains the department's responsibility. |
| 04 — Enterprise monitoring accounts | All telemetry is stored in the customer's Application Insights and Log Analytics workspace. Departments can grant CCCS/SSC read-only access per their standard procedures. See Logging, Monitoring, and Audit. |
| 05 — Data location | All data resides in the customer's Azure tenant in their selected Canadian region (Canada Central or Canada East) — including the optional AI Search, Azure OpenAI, and Document Intelligence resources, which deploy into the department's own subscription. License validation transmits only the tenant ID (via an Entra managed-identity token), API version, and the API's own base URL — no customer case data is transmitted to or stored by the publisher. The one optional egress, the Teams activity-feed notification payload, carries no requestor PII and can be minimised to routing identifiers or eliminated by self-hosting the relay; email and the in-app feed carry the same notices in-tenant. See Data Residency and Sovereignty and Teams Notification Data Sharing. |
| 06 — Protection of data at rest | Azure SQL TDE and Azure Blob Storage SSE (AES-256) enabled by default. Customer-managed keys (CMK) supported. See Encryption. |
| 07 — Protection of data in transit | TLS 1.3 enforced at the App Service front door (TLS 1.0/1.1/1.2 rejected); TLS 1.2+ on Azure SQL and Blob Storage. No plaintext endpoints. See Encryption. |
| 08 — Segment and separate | Single-tenant deployment with dedicated resources per customer — no shared compute, storage, or database. Blob paths and database queries are tenant-scoped. Network segmentation (Private Endpoints, VNet integration) can be added. See Data Residency and Sovereignty. |
| 09 — Network security services | The default deployment uses Azure PaaS public endpoints with platform-managed boundary protection. The template offers a built-in hardening option (deployNetworkIsolation=true) that places SQL and Blob Storage behind a virtual network reachable only by the App Service; departments can also add Private Endpoints, WAF (Application Gateway / Front Door), and NSG rules. |
| 10 — Cyber defense services | Microsoft Defender for SQL is enabled by default on the SQL logical server. Application Insights and Log Analytics data is accessible for integration with GC cyber-defense sensors and departmental SIEM. See Logging, Monitoring, and Audit. |
| 11 — Logging and monitoring | Immutable field-level audit trail in Azure SQL plus a hash-chained, append-only audit ledger with per-request case audit exports; an opt-in WORM blob container makes them write-once at the storage layer. Application Insights captures all API telemetry, with default metric alert rules (HTTP 5xx, latency). Log Analytics with configurable retention (30–730 days). See Logging, Monitoring, and Audit. |
| 12 — Configuration of cloud marketplaces | The SPFx web part and Teams app are distributed via Microsoft AppSource. The Azure backend deploys via a Bicep/ARM template — one-click from the Azure portal or scripted with a PowerShell script. Departments approve installations through their standard App Catalog and Azure governance processes. See Deployment Model. |
| 13 — Plan for continuity | Azure SQL automated backups, Blob Storage redundancy options, and a stateless App Service enable rapid redeployment (the API bundles its schema and applies it on startup). See Deployment Model. |
SA&A Process Guidance
When conducting a Security Assessment and Authorization for AccessPoint, departments should consider the following.
System Categorization
AccessPoint is typically categorized as PBMM when used for ATIP request processing. The system handles:
| Data Category | Classification | Rationale |
|---|---|---|
| Requestor PII (name, email, address) | Protected B | Personal information — serious injury if disclosed |
| Request records and descriptions | Protected B | May describe sensitive subject matter |
| Uploaded responsive documents | Up to Protected B | Classification depends on document content |
| Exemption decisions and rationale | Protected B | Disclosure could reveal deliberative processes |
| Audit trail and audit ledger | Protected B | Contain references to PII and request details |
| Application configuration | Internal | No sensitive data in configuration |
| Telemetry and logs | Internal | Performance data, no PII in telemetry |
Authorization Boundary
The AccessPoint authorization boundary comprises:
- The Azure App Service and its deployed application code
- The Azure SQL Database and all application data
- The Azure Blob Storage account and all stored documents
- The Application Insights and Log Analytics workspace
- The optional Azure AI Search, Azure OpenAI, and Azure AI Document Intelligence resources, when deployed (all in the department's own subscription with managed-identity-only authentication)
- The Entra ID app registration and the App Service managed identity
- The SPFx web part deployed to SharePoint Online and the Teams app package
- All data flows between these components
The following are outside the AccessPoint authorization boundary and fall under the department's broader Azure/M365 SA&A:
- The Azure subscription and resource-group configuration
- Entra ID tenant policies (MFA, Conditional Access, device compliance)
- Network configuration (VNet, NSG, Private Endpoints)
- Azure platform services managed by Microsoft
Leveraging Existing Assessments
- Azure platform controls (PE, portions of SC and CP) are covered by Microsoft's CCCS assessment for PBMM. Departments can reference the CCCS cloud service provider assessment for Azure rather than re-assessing platform-level controls.
- Entra ID and M365 controls are covered by the department's existing M365 SA&A. AccessPoint inherits MFA, Conditional Access, and identity governance from the department's tenant configuration.
- AccessPoint application-level controls (AC, AU, the application layer of IA/CM/SI, and IR) must be assessed by the department. The Technical Architecture page provides the detailed control documentation.
Key Documents to Request
When evaluating AccessPoint, your SA&A team may want to request:
| Document | Purpose |
|---|---|
| This page + Technical Architecture | Security control documentation |
| Vulnerability Assessment and Penetration Test (VAPT) results | Application security testing |
| Deployment Guide | Deployment procedure and post-deployment hardening |
| Dependency inventory | Supply-chain risk assessment (see Component Inventory; full dependency inventory available on request) |
| Incident response procedures | Vendor IR commitments (available from the publisher on request) |
| Privacy Impact Assessment | Personal information flows and privacy controls (see GC Privacy Impact Assessment) |
| Data flow diagrams | Data movement (see Architecture Diagram and Data Residency and Sovereignty) |