Trust & Security at Daylogue

Daylogue is a system for self-understanding. Pattern journaling is how it reads you: it compares information you chose to share and shows which entries contributed to a read. It does not diagnose, produce a clinical evaluation, or infer emotion from faces, voice tone, or physiology.

Daylogue is not therapy and is not a replacement for professional care.

These are the public boundaries for AI and organization use. The exact in-product disclosure controls when a particular role or feature has narrower limits:

• 1Daylogue does not infer emotion from faces, voice tone, or physiology.
• 2Employer-context dashboards are designed not to display individual entry text, transcripts, scores, or participation histories.
• 3Eligible employer aggregate views use self-reported information and appear only after the applicable contribution threshold is met.
• 4Voice and AI features disclose the relevant provider processing; entries are not end-to-end encrypted.
• 5Organization, coach, school, team, and Collab roles are not treated as interchangeable. Their fields and consent flows must be disclosed separately.

Full documentation: AI Safety.

Program status as of August 24, 2026. Daylogue does not currently have a SOC 2 report or attestation. Daylogue is preparing controls and evidence for a future readiness assessment. No independent SOC 2 audit has started or been scheduled.

The examination scope, audit type, and timing have not been set by an independent CPA firm. We therefore do not describe Daylogue as SOC 2 certified, compliant, attested, audit-ready, or under audit.

Internal preparation, policies, framework mapping, control tooling, or a vendor's certification is not a Daylogue attestation. Procurement teams may request current evidence for the specific controls they need.

Daylogue does not sell personal data. Disclosed service providers process data to operate requested features.

“We do not sell personal data” does not mean data never leaves Daylogue. The current subprocessor list explains which providers receive data and why.

Data locations can differ by provider and feature. Daylogue does not make a general promise that every processor or every copy stays in one country or region. Organizations with a specific residency requirement should request a current, feature-scoped answer from security@daylogue.com.

Daylogue does not claim HIPAA compliance and does not promise a Business Associate Agreement to general customers. Consumer self-reflection data can still be sensitive even when HIPAA does not apply.

Healthcare customers with BAA requirements should contact security@daylogue.com.

Daylogue does not use personal entries to train its own models. Provider handling follows current written terms, configuration, and subprocessor disclosures. Daylogue does not infer emotion from faces, voice tone, or physiology. It works from the words and context people choose to share.

• The current subprocessor list names the role of each AI and voice provider
• Provider access, storage, training use, and retention must be evaluated for the exact service mode and configuration
• Voice sessions may involve more than one disclosed provider; only the data required for the requested feature should be sent
• AI transparency: before a covered conversational check-in begins, Daylogue identifies the feature as AI and states that the user is interacting with an AI system, not a person. This is an operational disclosure, not a public legal conclusion about which law applies.

Full AI safety documentation

Some information Daylogue processes may be treated as consumer health data under state law depending on the information, how it is used, the person's location, and whether a law applies. Daylogue provides a separate Consumer Health Data Privacy Policy and rights process for transparency. This page does not claim that every check-in, transcript, narrative, or derived field has the same legal classification in Washington, Nevada, Connecticut, or another jurisdiction.

Consumer health data rights and policy

The canonical subprocessor list describes each verified processing role without implying a DPA, BAA, retention period, region, certification, or advance-notice commitment that has not been documented for that provider and mode.

Supported authentication methods use managed sessions and server-side authorization checks. Daylogue is re-verifying password, MFA, session-revocation, RLS, service-role, administrator, and support-path coverage before publishing more specific universal claims.

Daylogue uses operational logging and error monitoring to run and secure the service. Sensitive-field exclusions are being tested across normal and failure paths. Until that coverage is complete, Daylogue does not promise that every category of sensitive content is absent from every log, breadcrumb, diagnostic event, or support tool.

Daylogue does not use personal entries to train its own models. Provider handling is a separate question described on the AI Training Transparency page and the AI Trust Layer page.

Backups and provider recovery capabilities can retain data after it leaves active product views. Daylogue is re-verifying schedules, storage-layer protection, restore testing, retention, recovery objectives, and deletion propagation before publishing numerical assurances.

Suspected incidents are reviewed, and notices are provided according to applicable law, contracts, and the facts of the incident. Different events and jurisdictions use different triggers and deadlines.

A failed login or security alert is not automatically a reportable breach. Where notice is required, it will describe the known scope, affected information, and practical next steps.

You can access or delete your data at any time from Settings → Data & Privacy, or by emailing privacy@daylogue.com. Account deletion begins with a 30-day grace period when you can cancel the request. After that period, Daylogue begins deletion from active product systems. Backup, processor, billing, audit, legal, and user-authorized Collab retention limits are described in the Privacy Policy. Statutory access and deletion request deadlines can differ by jurisdiction and may permit extensions.

Detail and state-specific rights: Consumer Health Data Privacy and Privacy Policy.

Daylogue is not directed to children under 13 and does not knowingly collect personal information from children under 13 (COPPA). The product is intended for users 18 and older. If we learn we have collected data from a child under 13 without verifiable parental consent, we will delete it.

To report a security vulnerability, email security@daylogue.com. Response timing depends on severity and available information. Machine-readable contact information is published at /.well-known/security.txt (RFC 9116).

In scope

• The Daylogue web application at daylogue.com and its public APIs.
• The Daylogue iOS application, Apple Watch companion, and web app.
• Authentication, session management, and account-recovery flows.
• Data isolation between users and between organizations (RLS bypass, IDOR, tenant escape).

Out of scope

• Findings against third-party infrastructure we do not control (Supabase platform, Vercel platform, AWS, Stripe, Deepgram). Report those directly to the vendor.
• Reports requiring physical access, social engineering of Daylogue staff, or denial-of-service.
• Missing security headers, rate-limit hardening suggestions, and best-practice recommendations without a demonstrated impact.
• Self-XSS, clickjacking on pages without sensitive actions, and version-disclosure findings.
• Automated scanner output without proof of exploitation.

Reporting boundaries

Daylogue welcomes good-faith vulnerability reports. Please report promptly; do not access more data than is necessary to describe the issue; do not modify or delete data; do not disrupt the service; and do not publicly disclose an unresolved issue before coordinating with us. We will review reports and coordinate next steps based on severity, impact, and available information. This page does not grant authorization to test third-party systems, create a fixed disclosure deadline, promise immunity from legal action, or permit activity that violates applicable law.

Bug bounty

Daylogue does not currently operate a paid bug bounty program. Recognition may be offered after a report is validated and resolved, with the researcher's permission. Reporting does not create a payment, reward, response-time, or disclosure-timing obligation.

Acknowledgments

No public acknowledgments to date. Researchers credited here with their permission as reports are received and validated.

Need to complete a vendor security review? Submit the questionnaire below. The response will distinguish verified production controls from planned work and open review items.