Security Questionnaire

Amazon Web Services (AWS), ca-central-1 region (Montréal, Québec, Canada). All production infrastructure — compute, database, and secrets management — is in Canada.

Amazon Web Services (AWS).

Yes. Both the application server (EC2) and the database (RDS PostgreSQL 16) are in ca-central-1.

No. The database is hosted in a private subnet and is only accessible from the application server within the same network.

No CDN is currently in use.

Passwords are hashed using scrypt (N=16384, r=8, p=1, keylen=64) — a memory-hard key derivation function that meets OWASP minimum recommendations for interactive logins. The original password is never stored. Only the hash is retained.

Yes. Password comparisons use crypto.timingSafeEqual to prevent timing-based attacks.

Yes. Five consecutive failed login attempts trigger a 15-minute account lockout. The lockout is enforced server-side.

No. MFA is not currently implemented. Authentication uses email and password only.

Sessions use signed HS256 JSON Web Tokens (JWTs) stored in HttpOnly cookies. Cookie flags: HttpOnly (inaccessible to JavaScript), Secure (HTTPS only), SameSite=Strict (not sent on cross-site requests). Sessions expire after 8 hours absolute. There is no persistent "remember me" functionality.

Yes. A dummy hash computation is performed on unknown email addresses to prevent timing-based user enumeration.

Role-based access control (RBAC) with four levels: Facilitator (workshop hosting only), Read-only (view-only admin access), Admin (read-only plus room management), Super Admin (full administrative access including account management).

Yes. Authorization is re-validated against the database on every administrative request — not just at login. A session token with an elevated role is rejected if the database record shows a lower role or a suspended account. Role changes take effect immediately on the next request.

Yes. The application uses a runtime database user with read/write access to application tables only — no schema modification permissions. A separate migration user with DDL permissions is used only when applying schema changes and is not used by the running application.

Yes. All connections use TLS (HTTPS). HTTP requests are redirected to HTTPS. TLS certificates are issued by Let's Encrypt.

Yes. The connection between the application server and the database uses TLS with certificate verification (verify-full mode). The database does not accept unencrypted connections.

AWS RDS provides encryption at rest using AWS-managed keys. EC2 instance storage encryption depends on the AMI and volume configuration. Specific at-rest encryption configuration details are available on request.

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, environment files committed to version control, or deployment artifacts. At startup, the application fetches its secrets from Secrets Manager and injects them as environment variables.

No. The deployment pipeline uses AWS OIDC (OpenID Connect) for authentication, which provides short-lived, automatically rotated credentials. No long-term access keys are stored in the CI/CD system.

Yes. All administrative actions are recorded in an append-only audit log. The log captures: the action taken, the administrator who took it, the target of the action, the result, and a timestamp.

No. The application database user does not have UPDATE or DELETE permissions on the audit log table. Entries can only be appended.

No. The audit log records administrative actions only. Sensitive fields (passwords, tokens, participant data) are filtered before insertion using an allowlist.

One year. Cleanup is currently performed manually according to the documented retention policy.

Zero retention. Participant data is never stored. When a session ends, all participant data is gone. There is no retention period because there is nothing to retain.

Yes. Account deletion requests can be submitted via the contact form. There is no automated self-service account deletion currently.

Participant data is cleared automatically when a session ends (it is never stored). Retention cleanup for operational records (audit log, operational events, expired tokens) is currently performed manually according to documented retention policies. Automated cleanup is planned for a future platform update.

Deployments use GitHub Actions with AWS OIDC authentication. Every deployment passes through an active sessions gate (blocked if a live workshop is in progress) and a post-deployment health check (automatically rolled back if health validation fails).

Yes. If the post-deployment health check fails, the pipeline automatically rolls back to the previous release.

Yes. The deployment pipeline checks for active workshop sessions before proceeding. If any live sessions are in progress, the deployment is blocked until they complete.

Yes. A public health endpoint reports application status, database connectivity, migration status, and active room count.

External uptime monitoring is not currently configured. This is a known gap in the current operational model.

Security concerns and responsible disclosure requests can be submitted via the contact form. 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 use AI to score, evaluate, classify, or make decisions about participants.

Currently none. The platform uses AWS infrastructure (EC2, RDS, Secrets Manager) for hosting. The deployment pipeline uses GitHub Actions, which processes application code only — not user data. No third-party analytics, advertising, email delivery, or payment processing services currently process user data.

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.