Trust & Compliance

Because Onwards Upwards processes information about a person's emotional and psychological state, GDPR Article 9 special-category data is involved. We have completed an internal DPIA covering necessity & proportionality, risks to data subjects, and mitigating measures.

• Necessity: the service cannot function without the user's own journal entries.
• Lawful basis: explicit consent (Art. 9(2)(a)), captured at signup.
• Risks identified: unauthorised disclosure, re-identification, profiling.
• Mitigations: per-user Row-Level Security, encryption at rest and in transit, no third-party AI processing of entry content, minimisation of profile data, deterministic on-device-style aggregation for Insights.
• Residual risk: low. Reviewed annually and on material change.

The full DPIA is available to enterprise customers on request under NDA.

• Journal entries: kept until the user deletes them or closes the account.
• Profile + account: 30 days after closure (cooling-off), then permanently deleted.
• Audit log: 12 months from the event date.
• Email send log: 6 months from send date.
• Email suppression list: kept indefinitely (CAN-SPAM/PECR compliance).
• Backups: encrypted, rolling 30 days, then overwritten.

1. Detect: alerts from infrastructure monitoring, error logs, or user reports.
2. Triage (within 1h): on-call engineer classifies severity (SEV-1 to SEV-3) and confirms scope.
3. Contain (within 4h for SEV-1): rotate credentials, revoke sessions, block attack vectors.
4. Eradicate & recover: patch root cause, restore from clean backup if needed, verify integrity.
5. Notify: see Breach notification below.
6. Post-mortem (within 7 days): blameless review, corrective actions logged.

If a personal data breach is likely to result in a risk to your rights and freedoms, we will notify the relevant supervisory authority within 72 hours of becoming aware (GDPR Art. 33). Where the breach is likely to result in a high risk, we will also notify affected users without undue delay (Art. 34), including the nature of the breach, likely consequences, and steps you can take.

UK users: we notify the ICO. EU users: we notify the lead supervisory authority for our establishment. US users: we comply with state breach-notification laws (e.g. California Civ. Code §1798.82).

For business customers who process personal data of their own end-users through Onwards Upwards, our standard DPA (incorporating the EU Standard Contractual Clauses 2021/914 Module 2 and the UK Addendum) is available on request: dpa@onwardsupwards.app. For consumer accounts, the Privacy Policy and these terms govern processing.

Sub-processors are listed at /legal/subprocessors. We give customers 30 days' notice of new sub-processors via the same page; you may terminate without penalty if you object on reasonable data-protection grounds.

• Row-Level Security on every user table; admin queries audit-logged.
• AES-256 encryption at rest; TLS 1.2+ in transit.
• HIBP (Have I Been Pwned) password screening at signup and reset.
• Server-side input validation (Zod) on all mutating server functions.
• HSTS, X-Frame-Options DENY, X-Content-Type-Options nosniff, strict Permissions-Policy, Referrer-Policy.
• Append-only audit log for sensitive events (exports, deletions, profile changes).
• Vulnerability disclosure: see /.well-known/security.txt.
• Roadmap: SOC 2 Type II readiness, third-party penetration test, optional MFA enrollment.

We target WCAG 2.2 Level AA. Full statement and known issues: /legal/accessibility.

We rely on layered protections rather than a single ad-hoc rate limiter:

• Authentication endpoints (sign-in, sign-up, password reset, OTP) are rate-limited at the platform layer by our managed authentication provider, with both per-IP and per-account ceilings and exponential back-off on failed attempts.
• Public API routes under /api/public/* require HMAC-signature verification on every state-changing call. Unsigned or invalid requests are rejected before any handler logic runs.
• Outbound email is queued and throttled with provider-aware 429 back-off so that bursty events cannot drain our sending reputation.
• Bot & abuse signals from the edge (Cloudflare) are honoured at the network layer before reaching our application.

Application-layer per-route rate limiting is on the roadmap once our backend exposes a durable primitive that meets our observability and audit requirements.

Journal entries are encrypted with an envelope scheme: a per-row AES-256-GCM Data Encryption Key (DEK) wraps the payload, and the DEK is itself wrapped by a per-user Key Encryption Key (KEK) derived from a master secret held only in our secrets manager. The master secret never touches application logs or backups.

Rotation runbook (KEK master secret):

1. Generate a new 32-byte master secret offline. Add it as the secondary secret FIELD_ENCRYPTION_MASTER_KEY_NEXT without removing the current one.
2. Deploy a release that reads both secrets: the primary for new writes, the secondary for legacy reads. Envelope records carry a version column so each row is decryptable independently.
3. Run the background re-wrap job that streams each row, decrypts with the old KEK, re-encrypts with the new KEK, and bumps the version. Job is idempotent and resumable.
4. Once the row count at the old version reaches zero, retire the old secret and remove the dual-read branch in the next release.
5. File a rotation record in the audit log (event_type = security.key_rotation) with operator, start/stop timestamps, and row counts before/after.

Target cadence: every 24 months, or immediately on suspected compromise. Operator runs require two-person review (one to generate, one to approve the deploy).

Database backups are managed by our managed Postgres provider with the following posture:

• Encrypted at rest with provider-managed keys (AES-256) in the same region as primary storage. Journal payloads remain end-to-end encrypted inside the backup, so even a backup leak does not yield plaintext.
• Point-in-time recovery (PITR) with a 7-day window on the production tier, allowing per-second restore to any moment in the retention period.
• Daily snapshot retained for 30 days; the most recent snapshot is mirrored to a separate storage account for blast-radius isolation.
• Restore tests are performed at least quarterly into an isolated environment, with a documented Recovery Time Objective (RTO) of 4 hours and Recovery Point Objective (RPO) of ≤ 15 minutes.
• Erasure on backups: when you delete your account, live-system records are erased within 30 days and any references in encrypted backups age out within the 30-day snapshot window (90 days outer bound, see Privacy §7).

Because we offer services to data subjects in the EU and the UK while not being established there, we have designated representatives in line with GDPR Art. 27 and UK GDPR Art. 27. Supervisory authorities and data subjects may address them on all issues related to processing.

• EU representative: Onwards Upwards EU Representative, c/o Instant EU GDPR Representative Ltd, Office 2, 12A Lower Main Street, Lucan, Co. Dublin, K78 X5P8, Ireland — eu-rep@onwardsupwards.app.
• UK representative: Onwards Upwards UK Representative, c/o GDPR Local Ltd, 1st Floor Front Suite, 1 Quayside, Newcastle upon Tyne, NE1 3DA, UK — uk-rep@onwardsupwards.app.

Representative entries above are placeholders pending engagement of an Art. 27 service provider. Until finalised, escalate via privacy@onwardsupwards.app.