Information security policy

1. Overview

Synolo LLC ("Synolo") is committed to protecting the confidentiality, integrity, and availability of user data. This Information Security Policy outlines the technical and organizational measures we implement to identify, mitigate, and monitor information security risks across our platform.

This policy applies to all systems, data, and personnel involved in the operation of the Synolo application. For security questions, including responsible vulnerability disclosure, contact hello@synolo.app.

2. Data Classification

We classify data into the following categories to apply appropriate security controls:

• Highly sensitive: authentication credentials, API keys, OAuth tokens, financial access tokens (Plaid), and passwords. Always encrypted at rest and in transit; only the application itself accesses them.
• Sensitive: financial transactions, account balances, calendar events, contact details, and meeting recordings. Isolated per user and access-controlled.
• Standard: user-generated content such as notes, tasks, journal entries, and board entries. Stored in the application's encrypted database with per-user scoping; access is gated by request-time identity checks.
• Public: marketing content, documentation, and published policies.

3. Encryption

3.1 Data in Transit

• All client-server communication is encrypted using TLS 1.2 or higher, terminated at Cloudflare's edge.
• HTTPS is enforced on all endpoints with no fallback to unencrypted connections.
• API calls to third-party services (Plaid, Google, AI providers, payment processor) use TLS-encrypted connections.
• Off-site backups are uploaded over TLS.

3.2 Data at Rest

• All structured user data is stored in an encrypted SQLite database protected by SQLCipher (AES-256). The database file is unreadable without the master key, which is held only by the running application and never committed to source control.
• Sensitive credentials (Plaid access tokens, OAuth refresh tokens, internal service tokens, encrypted MFA secrets) are encrypted using AES-256-GCM with per-credential salts.
• Passwords are hashed using scrypt with per-user salts before storage. We never store passwords in plaintext or reversible form.
• MFA recovery codes are hashed using scrypt before storage and are single-use.
• Session tokens are signed using HMAC-SHA256 and stored in HTTP-only, secure, same-site cookies.
• Encrypted off-site backups are stored in Cloudflare R2 at rest.

4. Authentication and Access Control

• Password authentication with industry-standard hashing.
• Optional two-factor authentication via TOTP, compatible with Google Authenticator, Authy, 1Password, and similar authenticator apps. Eight single-use recovery codes are issued at enrollment.
• Re-authentication is required for sensitive account actions (changing email, deleting your account, managing MFA).
• Per-user data isolation: each user's data is scoped by user ID at the database layer. All API routes verify the requesting user's identity before reading or writing data. No user can access another user's data.
• Per-device session tracking: each login is tied to a hashed device fingerprint, IP, approximate city and country (from IP), and browser. Active sessions are visible at Settings → Security → Active Sessions and can be revoked individually or in bulk.
• Suspicious-activity alerts: we notify users by email of new logins from unfamiliar devices or locations.
• Least privilege in application code: every API route validates user identity and accesses only the minimum data required for the operation.
• Administrative access to production infrastructure, hosting providers, and third-party service dashboards is limited to authorized personnel and requires MFA on the underlying account.

5. Infrastructure Security

• Hosting: a Hetzner VPS in Nuremberg, Germany.
• Edge network: Cloudflare provides CDN, DDoS protection, TLS termination, and edge rate limiting for synolo.app.
• Backups: daily encrypted backups of all user data are uploaded to Cloudflare R2 with 30-day rolling retention.
• Content Security Policy headers are configured to limit script and resource origins, mitigating cross-site scripting (XSS) and other injection attacks.
• Rate limiting is in place on authentication, API endpoints, and AI usage, to protect against abuse, brute-force attacks, and denial-of-service.
• Input validation: all user input is validated and sanitized at the API boundary before processing.
• Atomic writes via database transactions: all data writes go through SQLite transactions, which guarantee atomicity. A write either fully succeeds or has no effect. SQLite journals writes to disk before acknowledging, so a crash mid-write cannot leave the database in a corrupt state.
• Trusted header policy: only Cloudflare-issued IP headers are trusted for rate limiting and audit logging, preventing client-side spoofing.
• Dependency management: third-party dependencies are tracked for known vulnerabilities and updated regularly.

6. Third-Party Integrations

We integrate with vetted third-party services. Each receives only the minimum data necessary for its function.

• Plaid (financial connections): bank credentials are entered directly into Plaid Link and never seen or stored by Synolo. Plaid access tokens are encrypted at rest with AES-256-GCM. Plaid is PCI-DSS Level 1 certified.
• Stripe (payments): all payment data is handled by Stripe. We store only the Stripe customer ID and subscription status. We do not see or store credit card numbers. Stripe is PCI-DSS Level 1 certified.
• Google APIs (sign-in and Calendar): OAuth 2.0 tokens are encrypted at rest. Refresh tokens are rotated when issued. Users can revoke access at any time via their Google Account settings.
• AI providers (OpenAI, Anthropic, Google): user content is sent only to these three providers via their official APIs (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com). Data is limited to what is necessary for the requested operation. We do not consent to use of your data for model training where provider opt-out is available. We are not currently on enterprise zero-retention tiers; provider-side handling otherwise follows their default API terms.
• Cloudflare (CDN and R2 storage): handles request metadata at the edge and stores encrypted backup archives.
• Sentry (error monitoring): receives error events including URLs, user IDs, and stack traces, but never the contents of your notes, tasks, calendar events, or messages.
• Brevo (email delivery): receives your email address and the content of transactional and announcement messages we send.

7. Data Retention and Deletion

• User data is retained for the duration of an active account.
• When you delete your account, all associated data, including notes, tasks, contacts, financial data, recordings, and files, is removed from our live servers immediately.
• Encrypted off-site backups in Cloudflare R2 follow a 30-day rolling retention. Deleted data may persist in backup form for up to 30 days before being permanently overwritten. We do not selectively restore deleted user data from backups.
• You can disconnect third-party integrations (Google, Plaid) at any time, which removes stored tokens and cached data for that integration.
• Meeting audio recordings are deleted from our servers immediately after transcription. Transcripts are kept as notes inside your account.
• Chat history retention varies by plan (7 days for Free Trial and Core; indefinite for Pro).

8. Incident Response

• Detection: application logs, system metrics, and Sentry error tracking are monitored for anomalous activity, unauthorized access attempts, and error patterns.
• Response: upon detection of a security incident, we investigate scope and impact, contain the issue, and implement remediation measures.
• Notification: affected users will be notified of any confirmed breach involving their personal data within 72 hours of confirmation, in accordance with applicable data protection regulations.
• Post-incident review: all security incidents are reviewed to identify root causes and implement preventive measures.

9. Vulnerability Management

• Third-party dependencies are regularly audited using automated tools (npm audit, GitHub Dependabot) and updated to address known vulnerabilities.
• Application code is reviewed for common security vulnerabilities (OWASP Top 10), including SQL/NoSQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), insecure deserialization, and broken access control.
• Security patches are applied promptly upon discovery of critical vulnerabilities.

10. Responsible Vulnerability Disclosure

We welcome reports from security researchers acting in good faith. If you believe you have found a security vulnerability in Synolo, please email hello@synolo.app with:

• A description of the issue and where you found it.
• Steps to reproduce.
• Any relevant logs, screenshots, or proof-of-concept.

We commit to:

• Acknowledging your report within 5 business days.
• Investigating and responding with a remediation plan or explanation.
• Not pursuing legal action against researchers who (a) act in good faith, (b) do not access or modify other users' data, (c) do not perform denial-of-service attacks, and (d) give us reasonable time to remediate before any public disclosure.

11. Compliance Principles

Synolo is not certified under SOC 2, ISO 27001, HIPAA, or FedRAMP, and we do not claim such certifications. We design and operate the service consistent with the following:

• General Data Protection Regulation (GDPR) principles, including data minimization, purpose limitation, lawful processing, and the right to erasure.
• California Consumer Privacy Act (CCPA) rights for all users, regardless of jurisdiction.
• PCI-DSS compliance via our payment processor (Stripe, PCI-DSS Level 1). Synolo does not handle or store card numbers directly.
• Industry-standard cryptography: TLS 1.2+ in transit, AES-256-GCM at rest, scrypt password hashing, HMAC-SHA256 session signing.
• OWASP secure-coding practices in application development.

12. Risk Assessment

We periodically assess risks to the security of user data by evaluating:

• The sensitivity of data processed and stored.
• The security posture of third-party integrations.
• Potential attack vectors and threat models relevant to our architecture.
• Changes in regulatory requirements and industry best practices.

Risk assessments inform updates to this policy and our security controls.

13. Policy Review

This Information Security Policy is reviewed and updated at least annually, or more frequently as needed in response to changes in our systems, regulatory requirements, or the threat landscape.

14. Contact

For security-related inquiries, vulnerability reports, or questions about this policy, contact hello@synolo.app.