We are a small team building a platform for sensitive political campaign data. This page explains the safeguards in place today and which controls are on the roadmap. We update it as controls are added.
Application servers and customer data live on Canadian infrastructure. Limited categories of data are processed by third parties — see our Privacy Policy for the full list.
The application servers and primary database run on iDigital Internet Inc. infrastructure in Toronto, Ontario. Bulk and transactional email is delivered through AWS Simple Email Service in the Canada (Central) region in Montreal. Customer data and account credentials remain on Canadian soil.
Every connection to RidingDesk is secured with TLS 1.2 or higher. HTTPS is enforced site-wide and HSTS is preloaded so browsers never downgrade to plaintext.
Strict Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers are returned on every response. Same-site session cookies plus token-based CSRF validation protect state-changing requests.
Column-level encryption at rest for the most sensitive fields, automated intrusion detection, and SOC 2 alignment are on the security roadmap. We will update this page as those controls come into place.
Defence-in-depth is layered into the framework choices and the code itself, not bolted on at the perimeter.
Built on Next.js with parameterised database queries, validated input via Zod schemas at every API boundary, output escaping in templates, and strict CSRF and CORS policies. Common OWASP Top 10 attack classes (injection, XSS, broken access control) are mitigated by these patterns.
Production application errors are reported to Sentry. A custom scrubber redacts request bodies, cookies, sensitive headers, email-shaped strings, and PII-shaped query parameters before any event leaves the server, so error reports can't become a back-door PII leak.
Dependencies are tracked via npm and updated regularly. We monitor GitHub security advisories on direct dependencies and patch critical vulnerabilities promptly. Formal third-party penetration testing is on the roadmap.
Every change is committed to version control before being deployed. The deploy process pulls a specific Git SHA, builds the application, and restarts the runtime. Build failures block the restart so a half-built bundle can't replace a working one.
Every campaign's data is separated and every privileged action is logged.
Six built-in roles — Campaign Manager, Field Director, Communications Lead, Data Analyst, Volunteer, and Observer — determine what each team member can see and do. Custom roles are on the roadmap. Permissions are enforced at the database query level: every query is scoped to the requesting user's campaign and role.
Every privileged action is logged with timestamps, user identity, IP address, and the entity affected. The audit log is immutable from inside the application — nothing in the dashboard can edit or delete a log entry, including campaign managers.
JWT-based sessions are signed with a server-only secret and expire after 8 hours by default. Sessions refresh in the background while a user is active. Signing out invalidates the cookie immediately.
Each campaign's data is logically isolated. Application code enforces a campaign-id scope on every read and write, so one campaign cannot access another campaign's voter records, communications, or donations.
Where we are today, and where we're going.
Passwords are stored as bcrypt hashes with an industry-standard work factor. We never store plaintext passwords and we never write passwords to logs.
Authentication endpoints (sign-in, password reset, email verification) are server-side rate-limited to slow down credential-stuffing and brute-force attempts.
Every new account must verify its email address before it can use the platform. Verification tokens are single-use and expire after 24 hours.
Two-factor authentication (TOTP and WebAuthn), known-breach password screening, and account-lockout-on-failed-attempts are planned controls. They are not yet enabled.
We design around the laws Canadian campaigns actually need to satisfy.
Personal Information Protection and Electronic Documents Act
RidingDesk's privacy practices are built around PIPEDA. We implement the ten fair-information principles, support data-subject access requests, and have a designated privacy contact at [email protected].
Act respecting the protection of personal information in the private sector
For campaigns operating in Quebec, our consent, retention, and breach-notification practices are designed around Law 25 requirements. Specific privacy impact assessments will be performed for any new feature involving Quebec residents' personal information.
PIPA (AB/BC) and other provincial legislation
Where Alberta's or British Columbia's PIPA applies to a campaign, our access, correction, and consent mechanisms align with those acts.
Canada Elections Act
Audit logs and donation records are retained at least as long as Elections Canada's post-election filing window. The platform supports campaign-finance reporting workflows but does not act as the official-agent record-keeper of last resort — your official agent's own books and Elections Canada's filings remain authoritative.
If a security incident occurs that affects personal information held in your campaign, we will notify the affected campaign as soon as feasible — consistent with our obligations under PIPEDA section 10.1 and applicable provincial breach-notification law. The notice will describe what happened, what data may have been affected, what we are doing about it, and what steps you should take. We will also report breaches that meet the regulatory threshold to the Office of the Privacy Commissioner of Canada.
If you believe you’ve found a security vulnerability in RidingDesk, please email us. We’ll acknowledge your report and keep you informed during the remediation process. We do not pursue legal action against researchers acting in good faith and following standard responsible-disclosure norms.
Report to:
[email protected]Please give us a reasonable window to address the issue before any public disclosure. We don’t currently run a bug-bounty programme; we’ll acknowledge your contribution publicly (with your permission) once the issue is fixed.
We’re happy to walk through the platform’s security posture with prospective customers.
See our Privacy Policy for the full list of third-party processors.