Safe For The Office™
Trust Center

Data Security

The security controls implemented in Safe For The Office™ — encryption, authentication, authorization, audit logging, and secrets management.

Security At A Glance
  • All connections encrypted in transit using TLS
  • Passwords hashed using scrypt — a memory-hard algorithm
  • Database credentials stored in AWS Secrets Manager — never in code
  • Database connection encrypted end-to-end with certificate verification
  • Role-based access control with four permission levels
  • All administrative actions recorded in an append-only audit log
  • Deployment uses short-lived credentials — no long-term access keys

Encryption in Transit

All connections to Safe For The Office™ are encrypted using TLS. HTTPS is enforced — HTTP requests are redirected to HTTPS. TLS certificates are issued by Let's Encrypt and renewed automatically.

The connection between the application server and the database is also encrypted end-to-end using TLS with certificate verification (verify-full mode). The database does not accept unencrypted connections.

Password Security

Facilitator passwords are hashed using scrypt, a memory-hard key derivation function designed to resist brute-force and hardware-accelerated attacks. The parameters used (N=16384, r=8, p=1) meet OWASP minimum recommendations for interactive logins.

The original password is never stored. Only the hash is retained. Password comparisons use a timing-safe comparison function to prevent timing-based attacks.

Accounts are protected against brute-force login attempts: five consecutive failed login attempts trigger a 15-minute account lockout. The lockout is enforced server-side and cannot be bypassed by the client.

Session Security

Authenticated sessions are managed using signed JSON Web Tokens (JWTs) stored in HttpOnly cookies. The cookie flags applied are:

  • - HttpOnly — the cookie is inaccessible to JavaScript, protecting against cross-site scripting attacks
  • - Secure — the cookie is only transmitted over HTTPS
  • - SameSite=Strict — the cookie is not sent on cross-site requests, protecting against cross-site request forgery

Sessions expire after 8 hours. There is no persistent "remember me" functionality.

Authorization and Access Control

Safe For The Office™ uses a four-level role hierarchy:

  • - Facilitator — access to workshop hosting features only
  • - Read-only — view-only access to the administrative platform
  • - Admin — read-only access plus the ability to close or terminate rooms
  • - Super Admin — full administrative access including account management

Authorization is enforced at the database level on every 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.

Secrets Management

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. The secrets are not written to disk or logged.

Database Security

The database uses two separate access roles:

  • - Runtime user — used by the running application. Has read/write access to application tables only. Cannot modify the database schema.
  • - Migration user — used only when applying database schema changes. Has schema modification permissions. Is not used by the running application.

The database is hosted in a private subnet and is not directly accessible from the internet. Access is only possible from the application server within the same network.

Audit Logging

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. The application user cannot modify or delete audit log entries — only append new ones.

The audit log does not contain participant data, passwords, tokens, or session values. Sensitive fields are filtered before insertion.

Deployment Security

The deployment pipeline uses OpenID Connect (OIDC) to authenticate with AWS. This means deployments use short-lived, automatically rotated credentials — there are no long-term access keys stored in the CI/CD system. The deployment role is scoped to the minimum permissions required: artifact storage and deployment command execution.

Every deployment passes through two automated gates: an active sessions check (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).

What We Do Not Claim

Safe For The Office™ has not pursued formal security certifications such as SOC 2, ISO 27001, or FedRAMP. The controls described on this page are implemented and operational, but they have not been independently audited against a formal certification framework. Organizations with formal certification requirements should contact us to discuss their specific needs.

← Data Retention Data Residency →

Last reviewed: October 2026