ITSG-33 control mapping, GC Cloud Guardrails compliance, and SA&A reference for Canadian federal government departments
Last updated: March 29, 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.
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. Authorization boundary defined in the Shared Responsibility Model. |
| 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 GC cloud-first directive. Deploys entirely within the department's existing M365 and Azure tenant. |
| CCCS Cloud Security Risk Management | Shared responsibility model 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 filtering 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. 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, session management | Authentication and Identity, Authorization and RBAC, Privacy by Design |
| AU — Audit and Accountability | Logging, audit trail, monitoring, log retention | Logging, Monitoring, and Audit |
| CA — Security Assessment and Authorization | SA&A process, system boundary, continuous monitoring | Shared Responsibility Model, Compliance Considerations |
| CM — Configuration Management | Baseline configurations, change control, hardening | Configuration Management, Update and Patching Lifecycle |
| CP — Contingency Planning | Backup, disaster recovery, business continuity | Disaster Recovery and Business Continuity |
| IA — Identification and Authentication | Identity provider, MFA, credential management, federation | Authentication and Identity |
| IR — Incident Response | Incident handling, notification, reporting to CCCS | Incident Response |
| 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 — see Shared Responsibility Model |
| PL — Planning | Security plans, system authorization boundary | Platform Overview, Shared Responsibility Model |
| RA — Risk Assessment | Threat/risk assessment, vulnerability scanning | Shared Responsibility Model, Compliance Considerations |
| SA — System and Services Acquisition | Supply chain, third-party dependencies, vendor practices | Dependency Inventory, What the Publisher Operates |
| SC — System and Communications Protection | Encryption in transit, network segmentation, boundary protection | Encryption, Network Architecture, Tenant Isolation |
| SI — System and Information Integrity | Patching, vulnerability management, malware protection | Update and Patching Lifecycle, Configuration Management |
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 | Application-level RBAC with six distinct roles. Administrator role is separate from operational roles. Role assignments stored in Azure SQL and enforced at the API layer on every request. 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 is 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 to these resources 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). No data is transmitted to or stored by the publisher. See Data Residency and Sovereignty. |
| 06 — Protection of data at rest | Azure SQL TDE and Azure Blob Storage SSE enabled by default. Customer-managed keys (CMK) supported. See Encryption. |
| 07 — Protection of data in transit | TLS 1.2+ enforced on all connections. No plaintext endpoints. See Encryption. |
| 08 — Segment and separate | Single-tenant deployment with dedicated resources per customer. No shared compute, storage, or database. Network segmentation recommendations provided. See Tenant Isolation and Network Architecture. |
| 09 — Network security services | Default deployment uses Azure PaaS public endpoints with platform-managed boundary protection. Departments can add Private Endpoints, VNet Integration, WAF, and NSG rules. See Network Architecture. |
| 10 — Cyber defense services | 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 | Comprehensive audit trail in Azure SQL (immutable). Application Insights captures all API telemetry. Log Analytics with configurable retention (30–730 days). See Logging, Monitoring, and Audit. |
| 12 — Configuration of cloud marketplaces | SPFx web part and Teams app distributed via Microsoft AppSource. Azure backend deployed via Bicep ARM template and PowerShell script. Departments approve installations through their standard App Catalog and Azure governance processes. |
| 13 — Plan for continuity | Azure SQL automated backups, Blob Storage redundancy options, stateless App Service for rapid redeployment. See Disaster Recovery and Business Continuity. |
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 | Protected B | Contains 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 is defined in the Shared Responsibility Model section of the Technical Architecture. In summary, the boundary includes:
- Azure App Service and deployed application code
- Azure SQL Database and all application data
- Azure Blob Storage and all stored documents
- Application Insights and Log Analytics workspace
- Entra ID app registration and managed identity
- SPFx web part and Teams app package
- All data flows between these components
Leveraging Existing Assessments
- Azure platform controls (PE, portions of SC, 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 policies from the department's tenant configuration.
- AccessPoint application-level controls (AC, AU, IA application layer, IR, CM application layer, SI application layer) 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 | Understand deployment procedure and post-deployment hardening |
| Dependency inventory | Supply chain risk assessment (see Technical Architecture — Dependency Inventory) |
| Incident response procedures | Vendor IR commitments (see Technical Architecture — Incident Response) |
| Data flow diagrams | Understand data movement (see Technical Architecture — Data Flow and Network Architecture) |