Procurement FAQ

No. Participants join a workshop session by entering a display name and a room code in their browser. No account, email address, password, phone number, or registration of any kind is required. Participants are anonymous to the platform.

No. Participant responses and answers are held in the server's active memory only during a live session. They are never written to a database, log file, or any persistent storage. When a session ends — whether the facilitator closes it, it expires, or the server restarts — all participant data is immediately and permanently gone. This is enforced at the database schema level: the tables required to store participant data do not exist.

No. Participant display names are held in server memory only during the active session. They are never written to the database. When the session ends, the names are gone.

No. Because participant responses are never stored, there is nothing to export. Once a session ends, the responses are gone. The platform does not offer post-session response exports, analytics reports, or participant-level data downloads.

No. Participant IP addresses are not logged or stored anywhere in the platform.

All participant data — names, responses, and session state — is lost. Participants would need to rejoin the session. This is by design: the privacy-first architecture means there is no persistent participant data to recover from.

All persistent production data is stored in Canada using Amazon Web Services infrastructure in the ca-central-1 region (Montréal, Québec). This includes facilitator accounts, workshop room records, audit logs, and operational events. No persistent user data is stored outside Canada.

The database stores: facilitator account information (email, display name, password hash, role, status), workshop room records (room code, activity type, state, timestamps), administrative audit log entries, and anonymized room lifecycle events. It does not store participant names, participant responses, or any participant-identifying information.

Persistent production data is hosted in Canada. The deployment pipeline uses GitHub Actions, which processes application code only — not user data. Safe For The Office™ does not currently use third-party email delivery, payment processing, or analytics services that process user data. If any such service is added in the future, it will be disclosed in the Privacy Policy before activation.

Yes. The Data Residency policy documents the infrastructure in detail. For written confirmation suitable for a vendor assessment, contact us directly.

Facilitator accounts use email and password authentication. Passwords are hashed using scrypt, a memory-hard algorithm. Sessions are managed using signed JWT tokens stored in HttpOnly, Secure, SameSite=Strict cookies. Administrative access uses a four-level role hierarchy (facilitator, read-only, admin, super admin) with database-authoritative enforcement on every request.

The account is locked for 15 minutes. The lockout is enforced server-side and cannot be bypassed by the client.

Yes. All connections to the platform use TLS (HTTPS). HTTP requests are redirected to HTTPS. The connection between the application server and the database is also encrypted end-to-end with certificate verification.

Database credentials, session signing secrets, and other sensitive configuration values are stored in AWS Secrets Manager. They are never stored in source code, configuration files, or deployment artifacts. At startup, the application fetches its secrets from Secrets Manager and injects them as environment variables.

Yes. All administrative actions — logins, logouts, room management operations, and account changes — are recorded in an append-only audit log. The log captures the action, the administrator who took it, the target, the result, and a timestamp. The application cannot modify or delete audit log entries. The audit log does not contain participant data.

No. Safe For The Office™ has not pursued formal security certifications. The platform implements security controls appropriate to its scale and use case, but these controls have not been independently audited against a formal certification framework. Organizations with formal certification requirements should contact us to discuss their specific needs.

Zero. Participant data is never stored, so there is no retention period. When a session ends, all participant data is gone.

Facilitator account records are retained while the account is active. Account deletion requests can be submitted via the contact form.

Room records — which contain the room code, activity type, and timestamps, but no participant data — are currently retained indefinitely. An automated cleanup policy for completed rooms is planned for a future platform update.

The administrative audit log is retained for one year. Cleanup is currently performed manually according to the documented retention policy.

Safe For The Office™ is designed to support organizations operating under PIPEDA requirements. The platform applies privacy-first design, data minimization, purpose-based processing, and appropriate safeguards. This is not a formal PIPEDA certification claim, and it does not replace your organization's own privacy or legal review. See the PIPEDA Alignment page for details.

Yes. The Trust Center and Procurement Center provide detailed documentation. For written responses to specific PIA questions, contact us directly. We respond to every message personally.

No. Participant responses are not sent to any AI system, language model, or machine learning service. The platform does not score participants, evaluate behaviour, or make automated decisions about individuals. See the AI Policy for full details.

No. The platform uses one cookie: the authentication session cookie for signed-in facilitators and administrators. There are no advertising cookies, tracking pixels, analytics cookies, or cross-site tracking of any kind. See the Cookie Policy for full details.

Support is provided through the contact form. There is no phone support or ticketing system. Documentation is available through the Trust Center, Procurement Center, and platform help resources. See the Support Model page for full details.

Facilitators can request a password reset through the login page. A single-use reset token is generated and expires after one hour. Email delivery for password reset tokens is not yet implemented — this is a known limitation currently in the development roadmap. In the interim, password recovery requests can be submitted via the contact form.

Updates are deployed automatically through a continuous delivery pipeline using GitHub Actions. Every deployment passes through an active sessions gate (deployments are blocked if a live workshop is in progress) and a post-deployment health check (the deployment is automatically rolled back if the application does not pass health validation). Customers receive updates without any action required.