Canadian-owned.
Canadian-controlled.
Built in Canada for over twenty years. AssociationServer's intellectual property, ownership, and decisions all reside in Canada — and your data lives on Canadian soil with cross-region disaster recovery between Toronto and Quebec City.
Vendor sovereignty determines
who controls your platform.
For Canadian associations evaluating software vendors today, ownership structure matters. It determines which country's laws govern your vendor relationship, who controls the roadmap for the platform you depend on, and where the decisions about your data are made. Sovereignty is not a recent positioning shift for us — it's how we've operated for over twenty years.
Canadian Incorporated
Headquartered in Newmarket, Ontario for over twenty years.
Canadian-Controlled
No foreign parent. No foreign investors. No foreign board.
Canadian IP
All AssociationServer intellectual property held by Oasis in Canada.
Canadian Team
Decisions about the roadmap and your data are made in Canada.
Your data lives in
two Canadian regions.
AssociationServer is hosted on Microsoft Azure's Canada Central (Toronto) and Canada East (Quebec City) regions. Your data resides on Canadian soil, in Canadian data centres, and is not transferred outside of Canada in normal operation.
We use both Canadian regions deliberately, with cross-region backup configurations designed to protect against geographic disasters. If a regional outage affects one region, your data and operations can be restored from the other — and both stay within Canada. Our redundancy strategy doesn't quietly compromise residency by replicating outside the country, which is a common configuration choice that often goes unexamined.
Data resides in one region, with backups in the other for geographic disaster recovery.
AI features are optional.
And they stay in Canada.
AssociationServer includes two AI-assisted features: a support assistant and a natural language rules builder. Nothing in the platform depends on them. If they are not enabled, no customer data reaches an AI service at all.
Off by Default
AI features are disabled unless you choose to enable them. No platform function requires them. Declining AI is a supported configuration, not a degraded one.
No Access to Member Data
The rules builder works against your configuration and business logic. The support assistant works against product documentation. Member records are not available to either.
Your Choice of Tenant
Provision Azure OpenAI in your own Azure subscription, or let us host it on our Canadian infrastructure. Either way, inference runs in a Canadian region.
Two ways to run it. Both in Canada.
Where AI features are enabled, you choose where the Azure OpenAI resource lives.
In your own Azure subscription. The resource is provisioned in your tenant, in the Canadian region you select, under your keys. Retention and abuse-monitoring settings are yours to configure and audit directly, and consumption bills to you.
On our Canadian infrastructure. If you would rather not manage an Azure subscription, we host the resource in our Canadian environment and pass consumption through at cost, without markup.
Under either arrangement, inference is processed in a Canadian region and does not route outside it.
Where a feature requires context, the relevant content is passed as a transient prompt at the moment of use and is not retained afterward. Prompts and completions are not used to train Microsoft's or OpenAI's models. That is a contractual commitment under Microsoft's Data Protection Addendum, not a vendor policy statement.
Either hosting arrangement keeps inference inside Canada.
Production-grade protection. Out of the box.
Our default security configuration is appropriate for the data Canadian professional associations entrust to us. This is not a stripped-down baseline. It's the production-grade posture we apply to every deployment.
Encryption at Rest
All data encrypted in Azure SQL using Transparent Data Encryption (TDE) — Microsoft's enterprise standard. Database files, backups, and transaction logs are all encrypted on disk.
Encryption in Transit
All connections to AssociationServer use TLS encryption. Data moving between browsers, application servers, and the database is protected against interception.
Edge Protection
Azure Front Door fronts every deployment — providing DDoS protection, web application firewall, and traffic filtering at the edge before requests ever reach our infrastructure.
Column-Level Encryption
Sensitive fields can be additionally protected with column-level encryption and separate key management — applied where the data category warrants the extra layer.
No Payment Data Stored
We do not store credit card numbers or regulated payment information. Payment processing is handled by PCI-compliant providers who specialize in payment data security.
Operational Security
Database access is restricted, audited, and monitored. Authentication uses industry-standard practices. Backup integrity is verified routinely.
Genuinely strong protection against the realistic threats organizations actually face.
What you actually need
to worry about.
Vague security marketing is not useful when your board, your auditors, or your members ask real questions. We believe in being straightforward about which risks our security posture actually addresses.
Realistic Threats
What our security posture is actually designed to address.
- Phishing attacks against staff and members
- Credential theft and session hijacking
- Ransomware and malicious access
- Accidental disclosure or staff error
- Data loss from regional outages or disasters
Procurement Questions
Legitimate questions that require documented answers, distinct from active security threats.
- US CLOUD Act exposure (cloud provider jurisdiction)
- Quebec Law 25 Transfer Impact Assessment
- Foreign jurisdiction in vendor supply chain
- Data residency vs. data sovereignty distinction
- Internal policies on customer-controlled keys
The CLOUD Act, in proportion.
A topic that has received considerable attention in recent procurement discussions is the US CLOUD Act, which gives US authorities legal mechanisms to compel US-incorporated companies to produce data they hold, regardless of where that data is physically stored. Because Microsoft is a US company, Azure infrastructure is technically subject to this jurisdiction.
The CLOUD Act is not a realistic threat to the data our clients store with us. Canadian professional associations' membership records, event registrations, and operational data are not plausible targets of US law enforcement requests.
Microsoft's own published transparency reporting supports this assessment. According to Microsoft's disclosures, cross-border enterprise content disclosures represent approximately 0.008% of their global law enforcement demands, with no public sector customer involvement reported. Microsoft's published policies further state that they require valid legal process for any data request, target only specific accounts and identifiers, do not provide governments with direct or unfettered access to customer data, and do not provide governments with encryption keys or the ability to break encryption.
That said, the CLOUD Act has become a legitimate procurement question that some clients need to address in their internal risk assessments — particularly clients subject to Quebec's Law 25 or those with policies requiring formal documentation of jurisdiction risks. For these clients, we offer the configuration option described in the next section.
Customer-Managed
Encryption Keys.
For clients with elevated sovereignty requirements or specific regulatory documentation needs, we offer Customer-Managed Encryption Keys (CMEK) as an optional configuration.
Under CMEK, the encryption keys protecting your database are held under your organization's control rather than the cloud provider's control. Microsoft cannot decrypt your data without your active participation in the key access process. This provides a meaningful additional protection layer specifically designed to address compelled-disclosure scenarios involving the cloud provider.
Customer control is not limited to key management. Where AI features are enabled, the Azure OpenAI resource is provisioned in your own Azure subscription rather than ours — a separation that applies by design rather than on request.
Recommended For
CMEK is provided as an additional service with associated setup and ongoing management fees, reflecting the operational work involved in proper key management infrastructure.
With CMEK, encryption keys live under your organization's control, separate from the cloud provider.
Questions sophisticated
procurement teams ask.
Which AI provider does AssociationServer use?
Azure OpenAI, in a Canadian region. Clients choose whether the resource is provisioned in their own Azure subscription or hosted on our Canadian infrastructure; inference stays in Canada either way, and we pass consumption through at cost without markup. AI features are optional and disabled unless a client chooses to enable them. Prompts and completions are not used to train Microsoft's or OpenAI's models, which is contractual under Microsoft's Data Protection Addendum.
Does the AI have access to our member data?
No. The support assistant works against product documentation, and the natural language rules builder works against configuration and business logic. Neither has access to member records. Where a feature requires context, it is passed as a transient prompt at the moment of use and is not retained.
Where exactly is our data stored?
In Microsoft Azure's Canada Central (Toronto) and Canada East (Quebec City) regions. Operational data resides in one region with cross-region backups in the other for disaster recovery. Data does not leave Canada in normal operation.
Is AssociationServer compliant with PIPEDA?
Yes. We support our clients' obligations under PIPEDA, including data handling practices, breach notification, and the principles of consent, accuracy, and accountability that the legislation requires.
Is AssociationServer compatible with Quebec's Law 25?
Yes. We support Law 25 requirements including consent management and Privacy Impact Assessment documentation. For Quebec clients with specific TIA requirements related to foreign jurisdiction exposure, our CMEK option is the configuration we typically recommend.
Do you store payment card information?
No. Payment processing is handled by PCI-compliant payment providers who specialize in payment data security. AssociationServer does not store credit card numbers or other regulated payment information.
What happens if Azure has an outage?
Our cross-region backup strategy means a regional outage in one Canadian Azure region does not result in data loss. Recovery procedures are designed and tested to restore service from the alternate Canadian region.
Who owns AssociationServer?
Oasis Computing Inc., a Canadian-controlled private corporation headquartered in Newmarket, Ontario. The intellectual property in AssociationServer is held entirely by Oasis. We have no foreign parent, no foreign investors, and no foreign control over our roadmap or operations.
Is my data encrypted?
Yes, by default — at rest using TDE, in transit using TLS, and protected at the edge by Azure Front Door. Sensitive fields can be additionally protected with column-level encryption. Clients with elevated requirements can opt for Customer-Managed Encryption Keys.
What is Microsoft's position on government data requests?
Microsoft requires valid legal process for any data request, targets only specific accounts, does not provide direct government access, and does not surrender encryption keys. Cross-border enterprise content disclosures represent ~0.008% of their global law enforcement demands. Microsoft's full transparency reports are published on their website.
Can you support our internal Privacy Impact Assessment process?
Yes. We can provide the documentation our clients need to complete their PIAs and TIAs, including specifics on data handling, encryption configuration, geographic storage, and security controls. Contact us through your account representative or the link below.
How do I know which configuration is right for us?
For most associations, our default configuration is appropriate. CMEK is recommended for organizations with specific regulatory documentation requirements or internal policies requiring customer-controlled keys. We're happy to walk through the considerations with you and your team.
Have specific sovereignty
questions for your organization?
We'll walk through your data handling, your regulatory context, and whether elevated configurations like CMEK are right for your specific requirements — directly with someone who can engage substantively, not a generic sales response.
Last reviewed: 27 August 2026. Material changes to our security or sovereignty posture will be reflected here and communicated to clients in advance.