Scopingly Docs

Appearance

Security & privacy ​

Scopingly is built so that a signed-up organization's most sensitive content — its PRD and scope prose — is protected at rest, and so that authentication and administrative actions are guarded and observable. This page describes what that means for you.

Content encryption at rest ​

Your PRD and scope prose — the actual written content of your documents — is encrypted per organization before it is written to storage. A leaked database dump, backup, or snapshot yields ciphertext, not readable product content.

How it works, at a high level:

  • Envelope encryption, per organization. Each organization has its own data encryption key, which is itself wrapped by a platform master key. Your organization's content is encrypted under your organization's key.
  • Covered content. The encrypted-at-rest set is the prose in the document stores — PRD and scope content, version history, and collaboration snapshots — plus specific prose columns such as executive summaries, comments, Q&A messages, and gap anchor text.
  • What stays searchable plaintext by design. Titles and descriptions are not encrypted, because they power search and sorting. The derived full-text search and semantic-embedding indexes also hold searchable text; these are hardened at the infrastructure layer (encrypted volumes, network isolation, authentication) rather than app-encrypted, because search over ciphertext isn't possible.

Crypto-shredding on deletion

Because keys are per organization, deleting an organization destroys its encryption key. That renders all of the org's ciphertext permanently unrecoverable across every store at once — "deleted" means cryptographically unrecoverable, not merely rows removed. See data management.

What this does and does not defend against

Encryption at rest defends against a stolen dump, backup, snapshot, or replica. It does not claim to hide content from Scopingly's running application, which necessarily holds the key in memory to generate scope, run search, and build embeddings. This is encryption at rest, not zero-knowledge storage.

Authentication security ​

Sign-in is protected by several layers:

  • JWT sessions with revocation. Sessions are token-based, and a per-user token version lets Scopingly revoke all of a user's sessions at once (for example on a password reset).
  • Hashed passwords. Passwords are stored using bcrypt; the plaintext is never persisted.
  • TOTP multi-factor authentication. Users can enable app-based MFA.
  • Login lockout. Repeated failed logins lock an account, with a dedicated unlock flow to recover. Repeated failed unlock attempts re-lock, so the lockout can't be brute-forced.
  • Per-IP rate limiting. Authentication endpoints are rate-limited by IP — an unforgeable value — so a forged token can't mint unlimited attempts.

Users who sign in via SSO have no stored password; their recovery path is a successful SSO sign-in, and if SSO is removed on a plan change they are migrated to a password account (see SSO downgrade).

Encrypted caching ​

Scopingly's Redis cache stores encrypted payloads, so cached content is not readable from the cache layer either.

Audit log ​

Business and above

The audit log records security-relevant and administrative actions in your organization — for example role grants, trial and billing changes, and org administration events — so you have an accountability trail of who did what.

Reading the audit log is a Business and above entitlement and is available to org admins. See the feature comparison for what each plan unlocks.

Scopingly.io — the Scoping Document Builder.

© Scopingly.io