Tarosyn Legal

Information Security Policy

Last updated May 31, 2026

This document sets out the internal procedures that put Tarosyn's security commitments into practice. Where the public overview describes what we protect and the principles we follow, this policy describes how those principles are operationalised day to day. It applies to all engineering and operations personnel, automated services, and any third party granted access to production systems or user data.

1. data classification tiers

Every piece of data Tarosyn stores is assigned to one of four classification tiers. The tier determines how the data is stored, who may access it, and how access is logged. When in doubt, data is treated at the higher (more restrictive) tier.

Tier 0 Public

Examples: Marketing pages, public blog posts, gallery cards explicitly shared, store listings.

Handling: No access restrictions. May be cached and distributed freely. Still subject to integrity controls so it cannot be tampered with.

Tier 1 Internal

Examples: Aggregated/anonymised metrics, non-sensitive operational logs, internal documentation.

Handling: Restricted to authenticated staff and services. Not exposed to end users. Least-privilege applies.

Tier 2 Confidential — user data

Examples: Readings, journal entries, DMs, birth-chart inputs, uploaded media, profile data, push subscriptions.

Handling: Encrypted in transit and at rest. Access scoped to the owning user or an explicitly permitted relationship. Staff access requires a session-bound credential and is audit-logged.

Tier 3 Restricted — secrets & credentials

Examples: Password hashes, session/guest/shadow tokens, Stripe references, API keys, signing keys, the session secret, database credentials.

Handling: Stored only in the secrets manager or hashed in the database — never in source, logs, or client storage. Access limited to the smallest possible set of services and engineers. Rotated on suspicion of compromise.

2. access provisioning & deprovisioning

Access to production systems and Tier 2–3 data follows a documented lifecycle built on least privilege. Access is granted only when there is a clear operational need and is removed as soon as that need ends.

Provisioning

Access requests are tied to a specific role and the minimum set of permissions that role requires — broad or standing admin access is avoided. A separate approver (not the requester) authorises any grant of production or Tier 2–3 access. Every individual receives unique, named credentials. Shared logins are prohibited for administrative systems. Multi-factor authentication is required before any production console or cloud-infrastructure access is activated. Automated services receive scoped service credentials, never a human's personal credentials, and bot API keys are excluded from high-privilege admin paths.

Review & deprovisioning

Access rights are reviewed on a recurring schedule and re-justified; anything no longer needed is revoked. On role change, access is re-scoped to the new role and any now-unnecessary permissions are removed. On departure, all access — accounts, credentials, tokens, and keys — is revoked promptly, and shared secrets the person could have known are rotated. Deprovisioning actions are recorded so the timeline of who had access to what can be reconstructed during a review or investigation.

3. incident response sla

When a security event is suspected, it is triaged by severity and handled against the following target response times. These targets cover acknowledgement and the start of containment — full resolution time depends on the nature of the incident.

Critical (Sev-1)

Active breach, confirmed unauthorised access to Tier 2–3 data, or full service outage.

Acknowledge within 1 hour. Containment begins immediately, 24/7.

High (Sev-2)

Credible exploitable vulnerability, suspected data exposure, or significant degradation.

Acknowledge within 4 hours during business hours. Containment plan within 24 hours.

Medium (Sev-3)

Lower-risk vulnerability or anomaly with limited blast radius.

Acknowledge within 1 business day. Remediation scheduled into the normal work queue.

Low (Sev-4)

Informational findings, hardening opportunities, defence-in-depth items.

Acknowledge within 3 business days. Tracked as backlog.

Where an incident results in unauthorised access to personal data, affected users and relevant regulators are notified in accordance with applicable law — see our Incident Response Policy for our breach-notification commitment. Every Sev-1 and Sev-2 incident is followed by a blameless post-incident review to identify root cause and prevent recurrence.

4. audit log retention

Security-relevant events are logged centrally so that access and administrative activity can be reviewed and reconstructed. Logs are themselves treated as sensitive and access to them is restricted and monitored.

Authentication events (login, OAuth/social callbacks, Apple/Google native sign-in, failed attempts) are captured with contextual metadata. Administrative and entitlement changes (moderation actions, tier changes, code-proposal review/apply, raw-SQL and migration runs) are recorded with the acting user and the method of authentication. Payment and subscription state transitions are audit-logged. Operational/application logs are retained for a shorter window for debugging and anomaly detection; security and audit events are retained for a longer window to support investigations and compliance. Logs are scrubbed of secrets, tokens, and raw private user content — log entries reference identifiers, not the underlying sensitive payloads. Retention windows are defined per log category; exact durations are confirmed with legal counsel and aligned to our Data Retention Policy.

Personal data captured incidentally in logs is governed by our Data Retention Policy.

5. employee security training

Every person with access to production systems or user data completes security training appropriate to their role, both at onboarding and on a recurring basis thereafter.

Security-awareness training is delivered at onboarding before production access is granted, and refreshed at least annually. Training covers phishing and social engineering, safe handling of Tier 2–3 data, secure credential and secret management, and how to recognise and report a suspected incident. Engineers receive secure-development guidance covering input validation, authorisation checks, SSRF and injection risks, and safe handling of secrets in code and CI. All personnel are bound by confidentiality obligations and acknowledge this policy and acceptable-use expectations. Reporting a suspected incident is everyone's responsibility — staff are trained to escalate immediately rather than attempt to resolve a suspected breach alone. related policies

This detailed policy works alongside our other security and privacy documents. For the high-level summary intended for users and partners, see the public overview; for breach handling, see the incident response policy.

Information Security Policy (public overview)

Security & Bug Bounty overview changes to this policy

This policy is reviewed and updated periodically to reflect changes in our practices, infrastructure, or applicable law. Material updates will be noted in the "Last Updated" date above. For questions, contact [email protected].

Security enquiries? [email protected]