Security and data
The questions a chief asks before a roster goes anywhere.
A department is trusting Semparo with its people's records. Here is exactly what is visible, who owns what, where it lives, and what happens to it, with the honest edges left in. Written to be forwarded to an IT reviewer, a privacy officer, and a budget approver.
Before you ask
The three questions every chief asks in the first ten minutes.
What can the department actually see?
Compliance on the training you assign, and the credential registry. That is the whole list. A member's personal preparation on Semparo, their own practice, their documents, their readiness for any other department, is never visible to any employer. It is engineered in, not just promised, and it is why members accept an employer-paid seat instead of resenting it.
See both views live in the demoWho owns the records?
The department does. Your roster, your credential records, and your training history are yours, and they leave in an audit-ready export whenever you want them, including on the way out. Semparo handles personal information under PIPEDA. Before any department signs, we put the data terms in writing rather than asking you to take a webpage's word for it. Ask for them and they come back in writing.
Read the privacy summaryWhat happens to a record when someone leaves?
A credential record belongs to the department's roster history and stays in the department's export, so an officer's departure does not take the evidence with it. That is the point of the probationary track too: quarterly evaluation notes that survive turnover, rather than living in the memory of whoever ran the file.
What we commit to in writing
Four commitments, before anything is signed.
Members keep a private product
The department sees compliance on the training it assigns and the credential registry. A member's own practice, documents and readiness for any other department are never visible to an employer. That boundary is enforced in the data model, not just promised in a policy.
The department owns its records
Your roster, credential records and training history belong to the department. They are not sold, not shared with another department, and not used to train AI models.
Your data leaves when you do
An audit-ready export is available whenever you want it, including on the way out. A record does not become a hostage to a renewal.
Handled under PIPEDA, in Canada
Semparo handles personal information under PIPEDA, and the database and uploaded files are stored in Canada. The data terms are put in writing before any department signs.
Built into the platform
What is in place today, and how it is enforced.
These are not aspirations. Each control below is live in the running system, and each is the kind of question an IT reviewer is paid to ask. Where a control belongs to a platform we build on rather than to Semparo directly, we say so.
Data residency
The application database and every uploaded credential file are stored in Canada. Roster records, training history and certificate scans do not sit in a US or offshore bucket. Supporting services such as hosting and email delivery are named in the subprocessor list below, and the hosting locations are documented for a department during procurement.
Encryption
Traffic to and from Semparo travels over TLS/HTTPS everywhere, so a record is encrypted on the wire between a member's browser and the server. At rest, the managed PostgreSQL platform encrypts stored data at the storage layer. We do not claim a bespoke Semparo cipher on top of that: we rely on the platform's at-rest encryption and tell you so plainly.
Access control
Authentication runs on Supabase, and every table is protected by Row-Level Security. Access is scoped per user and per department in the database itself, so a query can only ever return the rows the signed-in account is entitled to. The rule is enforced below the application, not by application code that could be bypassed.
The member and department boundary
This is the core Hall promise, and it is a data-model fact. Row-Level Security separates what a department can read from what belongs to a member alone. A department cannot query a member's personal practice, documents or readiness for another employer, because the policies that would return those rows do not grant it to the department. Engineered in, not left to trust.
Payments
Billing runs through Stripe. Card numbers are entered on Stripe's own surface and never reach Semparo's servers. Semparo sees the subscription behind a hall's access, its status and renewal, but it never sees or stores a card number. Card-data risk stays with a PCI-compliant processor rather than with us.
Audit logging
Security-relevant events are recorded to a dedicated audit table in the database, so meaningful actions leave a trail rather than vanishing. The exact event catalogue, how long entries are kept, and what a department can be shown from it are set out in the written data terms.
Who else handles the data
The subprocessors, named.
Parts of Semparo run on services we do not own. Here is the list a privacy officer will want. The current, authoritative list is provided in the written data terms and can change with notice to the department.
- VercelApplication hosting and content delivery
- SupabaseManaged PostgreSQL database, authentication and file storage, in Canada
- StripePayment processing (card data never reaches Semparo)
- ResendTransactional email delivery
Agreed in writing
Retention, incidents, backups and support.
These are the areas where the honest answer is that the specifics belong in the data terms a department signs, not on a public page. Each card says plainly what is shipped and what is committed rather than dressing an intention up as a control.
Retention and deletion
In the written data termsA department owns its records and can pull an audit-ready export at any time, including on exit. Members can already delete their own certificate scans and Personal History Statement drafts from the pages those live on. Account-level and department-level deletion is handled by request today rather than self-serve, and the specific retention periods for a department's data are fixed in the written data terms before signing.
Incident response
In the written data termsSemparo is early-stage and does not publish a formal incident-response runbook or a fixed notification-time commitment on this page. What a department is owed in the event of a security incident, including how and when it would be notified, is written into the data terms rather than left implied. Ask, and the commitment comes back in writing.
Backups
Discussed with the departmentThe database runs on a managed PostgreSQL platform. We are deliberately not quoting a backup schedule, recovery-point or recovery-time number on this page, because we will not print a figure we have not committed to in writing. A department's backup and recovery expectations are set out and agreed in the data terms, and we are happy to walk an IT reviewer through the current arrangement.
Availability and support
Honest about our stageHosting and delivery run on Vercel. We do not advertise a published uptime percentage or a round-the-clock support desk, because Semparo is new and no department has yet run a year on Hall. A department's support channel and response expectations are agreed directly with us and put in writing, so what you are promised is what we can actually stand behind.
Getting started
Implementation and onboarding.
Standing up a hall
A department is set up as its own account with its own roster. There is no hardware to install and nothing to run on the department's network: Semparo is reached in a browser. Members are added to the roster, and the training officer assigns banks and written exams with due dates from there.
Paperwork first, honestly
The data terms are put in writing and agreed before a roster is loaded, not after. Because Semparo is new and no department has yet completed a full year on Hall, we will build onboarding around a hall's own way of working rather than pointing you at a rigid template, and we will tell you where we are still early.
What we will not claim yet.
Semparo launched in July 2026 and is new. We do not hold a SOC 2 report, ISO 27001 certification, or any third-party security audit yet, and this page does not pretend otherwise. We do not publish a fixed uptime percentage, a formal recovery-time or recovery-point guarantee, or a round-the-clock support desk. Where a formal certification or a hard number would be the reassuring thing to write, we would rather be a department that tells you the truth about its stage. The commitments that a department is owed, on retention, incidents, backups and support, are the ones we put in the written data terms and stand behind. Ask us, and it comes back in writing.
Forward this part
The plain-language version, for whoever asks "is this safe?"
A volunteer hall does not always have an IT reviewer; sometimes the answer goes to a municipal clerk, a CAO, or an insurer. This is the whole page in one screen, in plain language, ready to email or print.
Semparo Hall is a training and credential system for Canadian fire departments. This is the short version of everything above, written to be forwarded.
Who can see what
- The department sees compliance on the training it assigns, and the credential registry. That is the whole list.
- A member's personal preparation, their own practice, documents, and readiness for any other department, is never visible to the department. This is enforced in the database, not just promised in a policy.
Where the data lives
- The application database and every uploaded credential file are stored in Canada.
- Personal information is handled under PIPEDA, Canada's federal privacy law.
- Four external services are involved, and we name them: Vercel (hosting), Supabase (database and authentication, in Canada), Stripe (payments; card numbers never reach Semparo), and Resend (email delivery).
How it is protected
- Traffic is encrypted in transit everywhere, and the managed database platform encrypts stored data at rest.
- Access is controlled per user and per department in the database itself (Row-Level Security), so an account can only ever read the rows it is entitled to.
- Security-relevant events are recorded to a dedicated audit table.
If the department leaves
- The department owns its roster, credential records, and training history, and can take an audit-ready export at any time, including on the way out.
- Records are not sold, not shared with another department, and not used to train AI models.
What we do not claim
- Semparo launched in July 2026 and does not yet hold a SOC 2 report, ISO certification, or third-party security audit, and we will not pretend otherwise.
- The specific commitments on retention, incident notification, backups, and support are put in the written data terms a department signs, so what you are promised is in writing, not on a webpage.
The email opens in your own app with no recipient filled in, so you choose who sees it. Questions come back to hall@semparo.ca.
The full data-processing terms are provided in writing to any department before it signs. The public privacy summary covers how Semparo handles personal information across the platform.