Security

How we protect your data

Last updated: March 2026

This document represents a self-assessment of our security practices. Papereg does not currently hold third-party certifications such as SOC 2, ISO 27001, or HIPAA. We are committed to transparency about what we do and don't have in place.

Architecture & Tenant Isolation

Papereg uses schema-based multi-tenancy for workspace data isolation. Each workspace gets its own PostgreSQL schema, providing database-level separation of data between organizations.

  • Every database query is scoped to the tenant's schema using PostgreSQL's SET search_path
  • Workspace data (forms, submissions, files) cannot be accessed across schemas
  • Schema names are validated against a strict allowlist pattern before any DDL execution
  • Tenant schema creation and deletion are controlled through dedicated administration functions
Implemented

Authentication & Access Control

Passwords

All user passwords are hashed using bcrypt before storage. Plaintext passwords are never stored or logged.

Session Tokens

User session tokens are hashed with SHA-256 before database storage. Sessions are invalidated on logout and password change.

API Tokens

  • API tokens are hashed with SHA-256 — raw tokens are shown once at creation and never stored
  • Tokens are revocable and support configurable expiration (30d, 90d, 1 year, or unlimited)
  • Scoped permissions restrict what each token can access
  • Tokens are automatically invalidated when the creator loses workspace membership

Role-Based Access Control

Each workspace has four roles: Owner, Manager, Supervisor, and User. Permissions are configurable per workspace and per role. Owners always have full access.

  • 26 configurable permission keys across workspace, forms, registry, pages, reports, and apps
  • Field-level access control restricts individual form fields by role
  • Permissions are loaded once per session and cached for fast template checks
Implemented MFA / SSO

Data Protection

Encryption in Transit

  • HTTPS enforced in production via force_ssl
  • HTTP Strict Transport Security (HSTS) enabled
  • Database connections use SSL

Encryption at Rest

  • Sensitive integration secrets (OAuth tokens, API keys, signing secrets) are encrypted at the application layer using AES-GCM
  • Encryption keys are derived from the application's secret key base
  • Non-sensitive configuration values remain as plaintext for debuggability

Input Validation

  • Form submissions are validated against a server-side allowlist of visible, non-display fields
  • All user-generated HTML (markdown content, embedded media) is sanitized through an allowlist-based scrubber
  • File uploads are validated by content type and size before processing
Implemented

Audit Logging & Traceability

Papereg maintains audit logs for key data access and modification events:

  • Submission views, edits, and status changes
  • Data exports (CSV, Excel, PDF)
  • API access to submissions
  • Report generation

Audit logs capture the user, action, timestamp, and relevant metadata. Logs are stored in the tenant's schema and are accessible through compliance reports (e.g., HIPAA Access Log).

Implemented

Application Security

Protection Implementation Status
Cross-Site Scripting (XSS) Allowlist-based HTML sanitization for all user-generated content rendered as raw HTML Implemented
Cross-Site Request Forgery (CSRF) Phoenix built-in CSRF tokens on all state-changing operations Implemented
Server-Side Request Forgery (SSRF) Outbound URL validation blocks private/loopback/link-local/metadata IPs after DNS resolution Implemented
SQL Injection Parameterized queries via Ecto ORM; schema names validated against strict regex before DDL Implemented
Content Security Policy Explicit CSP headers on embed routes restricting script and frame sources Implemented
Rate Limiting Per-workspace API rate limiting; per-IP rate limiting on public form submissions Implemented
Dependency Scanning Sobelow for static analysis; mix_audit for known CVE checks Implemented
Penetration Testing Not yet conducted Planned

AI Processing Disclosure

Papereg uses Anthropic Claude for two features:

  • Form Extraction: PDF documents are analyzed to automatically generate form fields matching the document structure
  • Submission Extraction: Scanned filled documents (PDF, images) are analyzed to extract field values for pre-filling submission data

What data is sent to Claude?

  • PDF or image content of uploaded documents
  • Form field definitions (labels, types) for matching

What data is NOT sent?

  • User account information or credentials
  • Data from other workspaces or submissions
  • Workspace configuration or settings

Per Anthropic's API terms, data sent through the API is not used for model training.

Data Storage & Subprocessors

Papereg relies on the following third-party services to deliver its functionality:

Provider Role Data Processed
Anthropic (Claude) AI document analysis Uploaded PDF/image content for form and submission extraction
AWS S3 (or compatible) File storage Uploaded files, attachments, document scans
Resend Transactional email Email addresses, email content for notifications and event actions
Sentry (optional) Error monitoring Error stack traces, request metadata (when enabled)

Customer-enabled integrations: When a workspace connects to external apps (e.g., Zoho Bigin), submission data is sent to those services as configured by the workspace administrator. These integrations only activate when explicitly set up by the customer.

Availability, Backup & Recovery

Papereg is a hosted web application deployed on managed infrastructure.

Honest disclosure

We do not yet have formally documented backup schedules, recovery time objectives (RTO/RPO), or disaster recovery procedures available for customer review. We are working toward documenting these as part of our operational maturity roadmap.

Formal DR documentation

Incident Response

If you discover a security vulnerability or have concerns about the security of your data, please contact us immediately:

Honest disclosure

We do not yet have a formally documented incident response plan with defined SLAs for customer notification. This is planned as part of our operational maturity roadmap.

Formal IR plan

Security questions?

If you have questions about our security practices or need additional information for your procurement process, we're here to help.

Contact Us