Security & Trust

1. Encryption & Access Controls

Encryption in transit. All connections to talkingpaper.app use TLS 1.2 or higher. HSTS is enforced via Render's edge so browsers refuse insecure downgrades. Managed certificate issuance and renewal are handled by Render's TLS termination.

Encryption at rest (infrastructure). Postgres data and managed backups are encrypted at rest with AES-256 by Render's managed-database service. We do not operate the underlying disks ourselves; for the primary attestation see Render's database documentation and Render's security & compliance page.

Application-layer encryption. Journal entry bodies are additionally encrypted at the field level using EncryptedTextField (Fernet, AES-128 in CBC mode + HMAC-SHA-256) so that a compromise of the row-level database access path does not yield plaintext journal text. Implementation: talking_paper/payments/security.py; callers see plaintext as before via the standard from_db_value / to_python field hooks.

Infrastructure access. Production database and infrastructure access is restricted to named operators authenticated via the Render organisation. No direct database access is granted to customer-support staff; user-data lookups go through audit-logged staff-console flows (the EnforcementEvent immutable log; see § 2 below).

See our Privacy Policy for which data categories are covered by which controls, and our Subprocessor list for where customer data is stored and processed.

2. Application access controls

Internal access to production data is governed by the access_control_policy.md document (business-docs/security/access_control_policy.md), which covers role definitions, named-user requirements, quarterly review cadence, and offboarding.

• Production infrastructure (web, database, Redis, crons) is managed via the Render dashboard with named-user accounts.
• Staff accounts on the application itself are required to enrol a TOTP second factor before they can reach the admin surface. The middleware that enforces this is talking_paper/middleware/mfa_staff_gate.py; un-enrolled staff are redirected to the enrolment flow.
• Staff actions that affect customer accounts (suspensions, refunds, GDPR retention pruning) are written to an immutable in-database audit log (EnforcementEvent model; see talking_paper/users/models.py).

3. Secrets & key management

API keys, database credentials, and signing keys live in Render envVarGroups (see render.yaml); no production secrets are checked into the repository. The application-layer field-encryption key (FIELD_ENCRYPTION_KEY) is managed the same way and is required for EncryptedTextField to decrypt journal bodies on read.

A rotation procedure for the application-layer encryption key is part of our operational backlog and is co-ordinated with counsel before execution; the underlying TLS and disk-encryption keys rotate under Render's own operational schedule.

4. Backups and recovery

Postgres backups follow the cadence documented in runbooks/backups.md: daily snapshots managed by Render. We maintain a documented restore-drill procedure under runbooks/db_restore_drill.md with a drill-log scaffold so each drill is timed and recorded.

Our point-in-time-recovery (PITR) posture depends on the Render database plan tier. The current plan documents a 24-hour Recovery Point Objective (RPO); a tier upgrade decision is tracked separately for EU/UK rollout.

5. Incident response

The incident-response procedure (severity tiers, on-call rotation, customer-notification timing under GDPR Art. 33, post-incident review) is documented in incident_response_policy.md (business-docs/security/incident_response_policy.md).

Security incidents can be reported to security@talkingpaper.app.

6. Uptime monitoring

Render performs internal health-check restarts on the web service. External uptime monitoring (HTTPS check on the anonymous liveness probe at /health/live/) is documented in runbooks/observability_alerts.md so a third-party probe can verify availability independently of Render's internal signal.

7. Vendor & subprocessor management

New subprocessors and material vendor changes are reviewed against vendor_review_policy.md (business-docs/security/vendor_review_policy.md) and the accompanying due-diligence questionnaire (business-docs/security/vendor_dd_questionnaire.md).

Current subprocessors are published at /legal/subprocessors/. Material changes to that list are announced with the notice period stated in the Privacy Policy and DPA.

8. Vulnerability disclosure

To report a suspected vulnerability, email security@talkingpaper.app. Our full Vulnerability Disclosure Policy covers scope, out-of-scope items, the response SLA, and safe-harbor protections for good-faith researchers. The machine-readable contact file is published at /.well-known/security.txt per RFC 9116.

9. Customer agreements (DPA)

Our click-through Data Processing Agreement is published at /legal/dpa/. A wet-ink or DocuSign countersignature is available on request for B2B customers who require it.

10. What we do not claim

Talking Paper does not currently hold or advertise the following. We may pursue them in the future and will update this page when (and only when) we do:

• SOC 2 audit report.
• ISO 27001 certification.
• HIPAA covered-entity or business-associate status.
• End-to-end encryption — we do not offer this; journal text is decrypted server-side to provide AI features.
• Zero-knowledge architecture.
• A scheduled third-party penetration-testing cadence.

This is a deliberate honesty surface. If a customer procurement process requires any of the above, please contact us at support@talkingpaper.app so we can align on timeline.