10-2 is designed from the ground up to meet the security and compliance requirements of Canadian law enforcement information systems — including CCCS Protected B / Medium Integrity / Medium Availability standards and NPIS cloud guidance.
The National Police Information Systems has published an approved Security Clause Catalogue specifically for cloud SaaS, PaaS, and IaaS deployments. It defines exactly what security controls a vendor must implement — and 10-2 is built against those requirements.
The Canadian Centre for Cyber Security (CCCS) has assessed and authorized cloud service providers — including Microsoft Azure — for use with Protected B government information. Agencies do not need to build on-premise infrastructure to achieve Protected B compliance.
Microsoft Azure's Canadian regions have been assessed against CCCS standards for Protected B workloads. Federal departments, provincial governments, and public safety agencies across Canada already run Protected B systems on Azure — the same infrastructure 10-2 is built on.
10-2 is built against the NPIS Security Clause Catalogue and CCCS Protected B / PBMM standards from day one. Each new product feature is evaluated and built against these frameworks before release — so compliance is built in, not bolted on. Every security control on this page maps to a specific requirement in those standards, giving agencies a clear line of sight from our platform to the actual policy.
These controls are designed into the platform architecture from day one — not retrofitted after the fact. Each maps directly to CCCS PBMM and NPIS requirements for police cloud systems.
All data stored in 10-2 is encrypted at rest using AES-256. All data in transit is protected using TLS 1.2 or higher — consistent with ITSP.40.111 cryptographic requirements for Protected B information. Encryption is active at all times, including during backups and failover.
ITSP.40.111 Compliant DesignEach police service operates in a logically isolated environment. One agency cannot access, query, or observe the data of another. Tenant separation is enforced at the data layer — not just the application layer — so a misconfiguration at one level cannot expose another agency's records.
Multi-Tenant IsolationAccess to 10-2 requires multi-factor authentication for all users. MFA is enforced — not optional. Single Sign-On (SSO) is supported, meaning officers and staff use their existing agency credentials to access 10-2 — no separate passwords to manage. Agencies retain full control over who has access; user provisioning and deprovisioning is managed through your existing identity provider. Privileged administrative access requires additional controls consistent with NPIS guidance on personnel with elevated rights. No standing access is granted to organizational data without explicit authorization.
MFA Enforced SSO SupportedUsers are granted access only to what their role requires — officers see their own files; supervisors see their unit; administrators operate within strict boundaries. Contractor and platform personnel do not have standing access to agency data and require explicit approval to access any organizational record.
Least-Privilege DesignEvery access, query, modification, and administrative action is logged with a tamper-evident audit trail. Logs capture who accessed what, when, and from where — supporting chain-of-custody requirements and enabling security incident investigation consistent with NPIS forensic procedures.
Immutable Audit TrailThe platform is designed to support regular security assessments, penetration testing, and vulnerability scanning. Identified vulnerabilities are tracked and remediated according to a defined mitigation process — consistent with the NPIS requirement for Vulnerability Mitigation Reports and corrective timelines.
Continuous Assessment10-2 is designed with a documented Security Incident Response process. In the event of a security incident, agencies will be notified according to defined timelines. The process supports containment, eradication, and recovery — consistent with NPIS requirements and Canadian data breach obligations.
Incident Response PlanOrganizational data is backed up with sufficient redundancy and geographic separation so that the loss of a single facility does not result in data loss or service interruption. Recovery capabilities are designed to meet defined service level commitments — consistent with NPIS resilience requirements.
Geo-Redundant Backup10-2 is built on the principle of data minimization — one of the core controls in the CCCS ITSG-33 security framework and the Treasury Board's privacy directives. Report content and AI-assisted validation responses are processed in real time and not stored on the platform once processing is complete. 10-2 retains only what is operationally necessary — such as configuration, user access records, and audit logs — and nothing more. This architecture significantly reduces the risk profile of the platform: data that is not stored cannot be breached.
Data Minimization ITSG-33 Aligned10-2 is connected to a managed Security Operations Centre (SOC) that provides continuous, around-the-clock monitoring of the platform. Powered by Microsoft Defender, the SOC actively detects threats, anomalies, and suspicious activity in real time — not after the fact. Any security event triggers an immediate response from trained security analysts, ensuring threats are contained before they escalate. This is the same class of monitoring used by government and critical infrastructure operators across Canada.
Microsoft Defender Managed SOC 24/7When an agency ends its relationship with 10-2, all organizational data is returned and securely destroyed — including crypto-shredding of encryption keys to prevent recovery. No residual copies are retained by the platform or its sub-processors beyond what is necessary for legally required retention.
Crypto-Shredding on ExitThe following table maps 10-2's security design commitments to the specific frameworks and guidance documents that govern police cloud systems in Canada. All items reflect design intent for the production platform.
| Security Domain | Framework Reference | 10-2 Design Approach | Status |
|---|---|---|---|
| Encryption in Transit | NPIS §5.1 ITSP.40.111 | TLS 1.2+ enforced on all connections; CSE-approved cryptographic algorithms | Designed |
| Encryption at Rest | NPIS §4.2 ITSP.40.111 | AES-256 encryption for all stored data, metadata, and logs — uninterrupted including during failures | Designed |
| Data Residency | NPIS §4.2 PBMM | All data stored and processed in Microsoft Azure Canada East / Canada Central regions only | Designed |
| Identity & Access Management | NPIS §12 PBMM | MFA enforced; RBAC; no standing privileged access; approval required for admin data access | Designed |
| Tenant Isolation | NPIS §4.2 | Logical and cryptographic separation of each agency's data at the data layer | Designed |
| Audit Logging | NPIS §9 ITSG-33 | Immutable audit trail of all access and administrative actions; supports forensic investigation | Designed |
| Vulnerability Management | NPIS §9.3 | Regular assessments, pen testing; documented mitigation timelines; Vulnerability Mitigation Reports | Designed |
| Security Incident Response | NPIS §9.5 | Documented IR process; agency notification obligations; containment, eradication & recovery procedures | Designed |
| Backup & Recovery | NPIS §7.1 | Geo-redundant backups; no single point of failure; recovery within defined SLA commitments | Designed |
| Personnel Security | NPIS §12.1 | Security screening for personnel with access to Protected data; need-to-know enforced | Designed |
| Data Disposal | NPIS §4.14 | Crypto-shredding on contract termination; all agency data returned or destroyed; no residual copies | Designed |
| Sub-processor Transparency | NPIS §12.3 | Full sub-processor list disclosed; 14-day advance notice of new sub-processors; agency approval rights | Designed |
| Firewall & Network Security | NPIS §5.2 ITSP.40.062 | EAL4-equivalent firewall controls; untrusted network posture; Azure security groups enforced | Designed |
| Third-Party Assurance | NPIS §9.4 | Roadmap to SOC 2 Type II; ISO 27001 target; CSA CAIQ for interim transparency | Designed |
Canadian police data must remain subject to Canadian law and Canadian jurisdiction. 10-2 is built on Microsoft Azure's Canadian regions — the same infrastructure used by federal and provincial government agencies for Protected B workloads.
Data is stored and processed exclusively in Azure Canada East (Québec City) and Canada Central (Toronto). It does not leave Canada under any operating condition.
All data remains subject to Canadian law. No foreign jurisdiction has lawful access to your agency's data through our platform architecture.
Microsoft Azure has been assessed and authorized by the Canadian Centre for Cyber Security as an acceptable cloud provider for Protected B government workloads.
Your agency's report data is never used to train AI models, shared with other agencies, or made available to any party outside the explicit service relationship.
10-2 is built on Microsoft Azure — Canada's most widely deployed cloud platform for government and public safety applications. Azure's Canadian infrastructure has been assessed by CCCS and is used by federal departments, provincial governments, and public safety agencies across the country.
Azure provides the foundational security controls that allow 10-2 to meet Protected B requirements — including physical security of data centres, hardware-level encryption, network isolation, and government-grade compliance certifications that would be prohibitively expensive to replicate independently.
By building on Azure's Canadian infrastructure, 10-2 inherits a security baseline that has already been assessed against Canadian government standards — giving agencies confidence in the underlying platform while we build application-layer controls on top.
10-2 is in active development. We believe it's important to be completely transparent about where we are in the security and compliance process. The controls and architecture described on this page represent our design commitments — what we are building toward, not claims of current certification or formal authorization.
What we will not claim: We will not claim a formal Authorization to Operate (ATO), CCCS certification, or any compliance designation until those assessments have been formally completed by the appropriate authority. Claiming otherwise would be misleading to the agencies that trust us with their data.
What we are committed to: We are building 10-2 to meet CCCS Protected B / PBMM standards and NPIS cloud security requirements from the first line of architecture. Security is not a checkbox at the end of our development process — it is the framework inside which every technical decision is made.
What this means for early adopters: Agencies evaluating 10-2 during our early access period will have full visibility into our security documentation, architecture decisions, and compliance roadmap. We welcome security reviews from agency IT and security teams as part of the onboarding process.
10-2 uses artificial intelligence to analyze the text of police reports — checking charge selection, legal elements, and report completeness in real time. We believe agencies deserve a plain-language explanation of how that AI works and how it is kept secure, rather than vague reassurances.
The AI tools used by 10-2 are deployed entirely within a secured Microsoft Azure tenant. When a report is submitted for validation, the text is sent to the AI model inside that secured environment, analyzed, and a structured response is returned — all within the same protected boundary. The report content is not sent to external services, is not stored after processing, and is never used to train or improve any AI model. Your data goes in, guidance comes back, and nothing is retained.
Think of it this way: the AI operates like a knowledgeable consultant sitting inside a locked, monitored room that you control. The report is handed through a slot, reviewed, and handed back. The consultant never leaves the room, keeps no copies, and cannot share what they read with anyone outside.
The AI model used by 10-2 is deployed within a dedicated, secured Microsoft Azure tenant — the same Protected B-capable environment that governs the rest of the platform. Report data processed by the AI never leaves this controlled boundary and is not routed through public AI services or third-party endpoints.
Police report content submitted to 10-2 is never used to train, fine-tune, or improve any AI model — including Microsoft's underlying models. This is enforced through contractual terms with our AI provider and is a non-negotiable condition of our platform architecture. What your officers write stays with your agency.
Consistent with our data minimization principle, report content is processed in real time and immediately discarded. The AI receives the text, performs its analysis, returns the validation output, and the input is deleted. There is no persistent storage of report narratives or officer-written content on the platform.
10-2's AI provides structured, explainable feedback — not black-box decisions. Every piece of guidance the system returns is traceable to a specific legal element, UCR requirement, or checklist item. Officers and supervisors always know why a flag was raised and what would resolve it. The AI advises; the human decides.
10-2 is a validation and coaching tool, not an automated decision-maker. No charge is laid, no report is approved, and no action is taken by the AI alone. Every output is reviewed and acted upon by a human officer or supervisor. Accountability remains with the people who know the file — not the system.
10-2's use of AI is being developed in alignment with Canada's Directive on Automated Decision-Making and the forthcoming Artificial Intelligence and Data Act (AIDA) under Bill C-27. We are committed to conducting an Algorithmic Impact Assessment — see the Risk Assessment section below — and to publishing our AI governance approach as that framework matures.
Responsible deployment of a tool used in the justice system requires structured risk assessment — across cybersecurity, privacy, and the use of AI. 10-2 is committed to completing the following assessments as part of our path to production readiness.
A Threat and Risk Assessment (TRA) evaluates the specific threats facing a system — who might attack it, how, and what the consequences would be — and maps those threats against the security controls in place. Under CCCS guidance (ITSG-33), a TRA is a required step in the Security Assessment and Authorization (SA&A) process before a system that handles Protected B information can go into production.
10-2's TRA will be conducted against the CCCS threat environment applicable to law enforcement systems, covering threats from external actors, insider risk, and supply chain. Results will inform residual risk decisions made by agency security authorities.
A Privacy Impact Assessment (PIA) identifies how a system collects, uses, retains, and discloses personal information — and assesses the risks that handling creates for individuals. Under the Treasury Board Directive on Privacy Impact Assessment, a PIA is required for any federal program or system that involves personal information, and is strongly recommended practice for systems handling police data at any level of government.
10-2's PIA will document what personal information the platform touches (if any, given our data minimization architecture), the legal authority for that handling, and the safeguards in place. Our design goal is a PIA that confirms minimal privacy risk — consistent with our principle of processing and discarding, not storing.
An Algorithmic Impact Assessment (AIA) is the Government of Canada's framework for evaluating the risks of using automated systems to assist in decisions — particularly where those decisions affect individuals. The AIA is published by the Treasury Board of Canada Secretariat and is required under the Directive on Automated Decision-Making for federal institutions. It is increasingly expected of vendors supplying AI-assisted tools to government and public safety agencies.
10-2 will complete an AIA to assess the potential impact of our AI validation engine on officers, agencies, and ultimately individuals whose cases move through the system. Because 10-2 is a coaching and advisory tool — not an automated decision-maker — we anticipate a lower impact level, but we are committed to completing the assessment transparently and publishing the results.
→ Government of Canada: Complete the Algorithmic Impact Assessment ↗Talk to our team about our security architecture, compliance roadmap, or how 10-2 can fit within your agency's IT governance requirements.
Request a Security Briefing Back to Main Site