Security Statement — Me Journal

Document control · Version 1.0 · Classification Confidential — Legal · Created 2026-05-02 · Last updated 2026-05-22 · Owner N (Astronero Ltd) · Next review 2026-11-18 · Location legal/SECURITY_STATEMENT.md

| Version | Date | Author | Summary of change | |---|---|---|---| | 1.0 | 2026-05-22 | N / Claude | Doc-control header added; content pre-existing |

Last updated: 2026-05-02

DRAFT — to be reviewed by N (the founder, an ISO 27001-certified infosec professional) before publication. Items to verify or sharpen: the actual ISMS scope, the breach response timeline against Article 33's 72-hour requirement, the supplier audit cadence, the data-export turn-around commitment.

This page describes the technical and organisational security measures we take to protect your personal data on Me Journal. It is the public companion to our Privacy Policy and Cookie Policy.

If you spot something on this page that's wrong, missing, or you'd like to know more about — email security@me-journal.com.

1. Who we are, security-wise

Me Journal is operated by Astronero Ltd, a private limited company registered in England & Wales. Our founder is an information security professional with an MSc in cybersecurity, ISO 27001 lead auditor certification, and 10+ years' experience implementing ISMS frameworks.

Security is not an afterthought here. It's the founder's day-job discipline applied to their own product.

2. The data we protect

In order of sensitivity:

Journal entries, mood logs, gratitude entries — special-category personal data under Article 9 GDPR; sensitive personal information under CPRA
Programme entries — not legally special-category but personally private
Account data — email, name (optional)
Authentication data — handled by Clerk; we never see plain-text passwords
Payment data — handled by Stripe; we never see full card numbers
Operational data — server logs, push subscription endpoints

All categories are encrypted in transit and at rest (see § 3).

3. Technical measures

3.1 Encryption

In transit: TLS 1.2+ on every connection. We do not accept un-encrypted HTTP. HSTS preload submission is in plan post-launch.
At rest: Convex (our database) encrypts all stored data using AES-256. Cloudflare R2 (where founder videos and meditation audio live) also encrypts at rest.
Backups: Convex's daily snapshots are encrypted using the same keys; the backup system itself is operated by Convex under their SOC 2 controls.

3.2 Authentication

Provided by Clerk. They are SOC 2 Type II certified.
Passwords are never stored by Me Journal — Clerk handles the hashing (bcrypt with appropriate cost factor).
Multi-factor authentication (MFA) is available for all users via Clerk; we strongly encourage enabling it.
Session tokens are HttpOnly + SameSite=Lax + Secure (in production) cookies. They cannot be read by JavaScript.

3.3 Authorization

Every Convex query and mutation explicitly verifies the user's identity via ctx.auth.getUserIdentity() before returning data. There is no row-level-security shortcut — explicit checks are the only path.
Admin functions verify the Clerk publicMetadata.role === "admin" flag separately. Admin role assignment is a manual operation by the founder.
Server-side route loaders (like the dashboard layout) enforce signed-in status and tier checks before rendering authenticated pages.

3.4 Network and infrastructure

Hosted on Vercel (SOC 2 Type II) for the application layer
Database on Convex (SOC 2 Type II)
Authentication via Clerk (SOC 2 Type II)
Payments via Stripe (PCI DSS Level 1)
Object storage on Cloudflare R2 (SOC 2; ISO 27001)
All providers have signed Data Processing Addenda compliant with GDPR Article 28
We do not run our own servers, our own databases, or our own payment infrastructure — reducing attack surface and ensuring our underlying providers' security investments work for us

3.5 Application security

Dependency scanning: npm audit reviewed regularly; security advisories actioned within agreed timeframes (critical: 24 hours; high: 7 days; medium: 30 days)
Input validation: Convex's schema layer enforces the shape of every mutation argument; arbitrary input cannot reach the database
Output encoding: React's default escaping prevents XSS; we use dangerouslySetInnerHTML only on internal scripts (theme, service worker registration), never on user input. The one place we render user-generated HTML (journal-view) is on the radar for DOMPurify sanitisation (see our SECURITY_AUDIT.md M1 finding)
CSRF: mitigated by Convex's session-token model and React Router's CSRF protections
Secrets management: API keys live only in Convex / Vercel encrypted environment variables. They are never committed to source control. All assistant tooling on this project is rule-bound to never read or echo .env* files (per our internal secrets_rotation_backlog.md governance rule)

3.6 AI-specific safeguards

Crisis detection runs before every AI-generated response — pattern matching for self-harm / suicide / abuse indicators returns crisis- resource copy directly without any LLM call (convex/crisisDetection.ts).
Per-tier usage caps prevent any single user from consuming unbounded AI resources (convex/aiGate.ts).
Zero-retention configuration at the AI provider — Anthropic / OpenAI are not permitted to retain or train on Me Journal user content.
Tier-locked features registry (convex/tierFeatures.ts) — every AI feature must be registered, gated by tier, and reviewed before it ships.

4. Organisational measures

4.1 Access controls

Me Journal staff routinely have no access to user-content databases. The only times access is needed (for incident debugging, user-initiated support requests) are logged and time-limited.
Production database access requires MFA via Convex.
Code deployment requires GitHub access — protected by MFA.
Vercel + Convex + Cloudflare admin consoles all require MFA.

4.2 Vendor management

Every sub-processor undergoes a basic security review before being added (SOC 2 / ISO 27001 certification preferred; security documentation reviewed; DPA confirmed).
The current sub-processor list is published at https://me-journal.com/legal/sub-processors and updated within 30 days of any change.

4.3 Personnel

Currently a single founder. As the team grows, all staff with potential access to user data will:
- Sign confidentiality agreements
- Complete security awareness training before access is granted
- Have access reviewed every 90 days; revoked when no longer needed

4.4 ISMS framing

While Me Journal is not currently certified to ISO 27001 (the cost vs. benefit at our scale is hard to justify pre-launch), we operate against the ISO 27001 framework informally:

A Statement of Applicability is maintained internally
Risk assessments are documented and reviewed quarterly
Incident response procedures are written, tested, and reviewed
Access control policies are written and enforced
Backup and disaster recovery procedures are documented

We expect to seek formal ISO 27001 certification once we reach a scale where the audit cost is proportionate.

5. Incident response

If a personal data breach occurs that affects our users:

Containment: within 24 hours of identification, the breach is contained (access revoked, vulnerability patched, affected systems isolated as needed)
Notification to supervisory authority: within 72 hours of becoming aware (UK GDPR + EU GDPR Article 33), a notification is filed with the Information Commissioner's Office (ICO) and any other relevant regulator
Notification to affected users: if the breach is likely to result in a high risk to your rights and freedoms (Article 34 / equivalent in CPRA), we email you directly with:
- A description of what happened
- The likely consequences
- The steps we've taken
- Steps you should take (e.g. change password, enable MFA)
Post-incident review: within 30 days, a written review is completed, root causes documented, and corrective actions tracked to closure
Public statement: for material breaches, a public post-mortem is published on our blog within 60 days

We do not bury security incidents. We tell users.

6. Your security obligations

To keep your account secure:

Use a strong, unique password — your account is only as secure as this credential
Enable MFA via Clerk (Settings → Security)
Don't share your password or sign-in link with anyone
Sign out from shared devices when you finish
Tell us immediately if you suspect unauthorised access: security@me-journal.com

7. Vulnerability disclosure

If you discover a security vulnerability in Me Journal, please report it to security@me-journal.com. We commit to:

Acknowledging receipt within 5 business days
Providing a status update within 14 days
Patching critical vulnerabilities within 7 days (or ASAP)
Crediting you publicly (with your permission) once the fix ships

We do not currently operate a paid bug bounty programme, but we do celebrate good-faith researchers and we will not pursue legal action against researchers acting in line with this policy.

In scope:

The Me Journal web application at https://me-journal.com
Our public Convex API endpoints
Our subdomains and admin paths

Out of scope:

Social engineering
Physical attacks
Denial-of-service testing
Issues in upstream providers (Convex, Clerk, Stripe, Vercel, Cloudflare) — please report those directly to the provider

8. Contact

Security questions, vulnerability reports: security@me-journal.com
Privacy questions: privacy@me-journal.com
General contact: support@me-journal.com