Data Sovereignty

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.

Why This Matters

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.

Regional Storage

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 stays in Canada Cross-region disaster recovery No US-region replication
Canada Central Toronto Canada East Quebec City

Data resides in one region, with backups in the other for geographic disaster recovery.

Default Configuration

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.

Honest Threat Modeling

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

Real questions for documentation purposes — not realistic threats to association data.

  • 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.

Available on Request

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.

Recommended For

Clients subject to Quebec's Law 25 documenting TIA mitigations
Public sector or quasi-public organizations with key-management policies
Regulated sectors with specific data sovereignty requirements
Boards or legal counsel requesting CMEK as part of vendor diligence

CMEK is provided as an additional service with associated setup and ongoing management fees, reflecting the operational work involved in proper key management infrastructure.

DEFAULT CONFIGURATION CLOUD PROVIDER (MICROSOFT AZURE) Encrypted Database Encryption Keys WITH CMEK CLOUD PROVIDER Encrypted Database YOUR CONTROL Encryption Keys Microsoft cannot decrypt without your active participation.

With CMEK, encryption keys live under your organization's control, separate from the cloud provider.

Frequently Asked

Questions sophisticated
procurement teams ask.

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: [Date]. Material changes to our security or sovereignty posture will be reflected here and communicated to clients in advance.