SOC 2 Type I AttestedSundial is SOC 2 Type I attested.

Enterprise Security Review

Last Modified: October 28, 2025

Summary

Sundial is a Chrome extension that enhances scheduling efficiency in Google Calendar. See how it works here.

This page outlines Sundial’s security and compliance approach for enterprise review. For inquiries, contact support@trysundial.ai.

  • SOC 2: Type I attested (Aug 2025); Type II review ready in November 2025. Live controls status.
  • Independent Security Testing: Regular third-party penetration testing. Latest certification available here.
  • Enterprise Integration: Supports SAML 2.0 SSO.
  • Data Minimization: No passive tracking. Only accesses calendar when user-initiated. No event data retained.
  • Data Control: Users and enterprises can delete data anytime via dashboard or by request.

Table of Contents

1. Permissions & Data Access

1.1 Chrome Permissions

  • storage: Saves user preferences.
  • background: Maintains extension functionality without tracking user activity.
  • activeTab: Temporarily grants permissions for Google Calendar access.
  • scripting: Injects scripts to enhance scheduling features.

1.2 Host & API Permissions

Host Permissions

  • calendar.google.com: Reads and modifies Google Calendar upon user request.

API Permissions:

  • Cloud Firestore: Stores user preferences and feature usage data.
  • Google OAuth (userinfo.email scope): Handles secure authentication for Google services and identifies the user’s account by email address for Firestore association and feature access control.
  • Google Calendar API (events scope): Enables event creation, deletion, and audit functions upon user request.
  • Google Drive API (drive.file scope): Creates a new Google Sheet in the user’s Drive for Calendar Audits. No other Drive files are accessible.
  • OpenAI API: Processes user-provided text to extract meeting dates, times, and timezone (ephemeral, no data stored).

2. Data Security & Storage

2.1 Data Collection

  • User Identifiers: Email address from authentication.
  • Usage Data: Feature interactions to improve functionality.

2.2 Storage & Encryption

  • Local Storage: Stores user preferences and temporary UI states to retain user actions during a session.
  • Cloud Firestore: Stores user email and feature usage data.
  • OAuth Security: Tokens are short-lived and auto-refreshed; not stored.

2.3 Data Processing

  • Google Calendar Data: Processed only for Bulk Create and Delete Calendar Holds and Calendar Audit features; no calendar event details stored.
  • Scheduling Text: User provided text is processed via a fine-tuned LLM (OpenAI’s GPT-4.1 Mini) to extract meeting times; no storage or AI training usage.

2.4 Data Residency

  • Cloud Firestore: Stored in nam5 region; no calendar event details retained.

2.5 Data Deletion Policy

  • User Requests: Users can request data deletion via support@trysundial.ai.
  • Enterprise Deletion Requests: Organizations may request full deletion of their users’ data.

3. Authentication & User Identity

3.1 Authentication Methods

  • Google OAuth 2.0: Primary authentication method required to use Sundial.
  • Enterprise SSO: Supports SAML 2.0 for enterprise single sign-on integration.

3.2 Authorization & Access Control

Scoped API Access: Sundial follows the principle of least privilege. All access is explicitly user-initiated; no background data collection occurs.

  • googleapis.com/auth/userinfo.email: Requested during sign-in to identify the user’s Google account and securely associate preferences and usage data with that account in Firestore.
  • googleapis.com/auth/calendar.events: Requested when users explicitly use features that modify their calendar, such as Bulk Create Holds, Bulk Delete Holds, or Calendar Audit.
  • googleapis.com/auth/drive.file: Requested only when users generate a Calendar Audit, allowing Sundial to create and populate a new Google Sheet in the user’s Drive. Sundial cannot view or edit any other files in your Drive.

4. Application Architecture

4.1 System Components

  • Chrome Extension Frontend: Injects scripts into Google Calendar only upon explicit user interaction.
  • Cloud Firestore: Stores feature usage per user.
  • Google Calendar Events API: Used for features that interact with events (Bulk Create/Delete Holds, Calendar Audit).
  • Google Drive File API: Used only to create new Google Sheets in the user's Drive during the Calendar Audit feature. The sheet is filled locally in the browser. And Sundial has no ability to view, edit, or access any other files in your Drive.
  • Render.com: Backend service relaying API payloads to OpenAI.
  • Fine-tuned LLM (OpenAI’s GPT-4.1 Mini): Ephemerally processes meeting time extraction from user provided content.
  • No Proprietary Backend: Relies on Google Cloud infrastructure.
  • Frontend Hosting (Netlify): Used for team dashboard.

4.2 Secure Communication

  • HTTPS/TLS Encryption: All communications use TLS 1.2+.
  • OAuth Token Security: Tokens are short-lived and not stored.
  • No Passive Data Interception: No tracking, logging, or collection of any user activity outside of explicit Sundial interactions.

5. Compliance & Privacy Considerations

5.1 Regulatory Compliance

  • SOC 2: Sundial achieved SOC 2 Type I attestation in August 2025. For a copy of the report, please email support@trysundial.ai. Our SOC 2 Type II review period is underway and is set to be complete in November 2025. You can review the live status of our controls anytime here.
  • GDPR: Sundial follows data minimization principles. Users retain full control over their data and can request deletion at any time.
  • CCPA: No user data is sold or shared with third parties.
  • HIPAA: Sundial does not store or retain any PHI beyond user email address.

5.2 Privacy & Security Certifications

  • Penetration Testing: Sundial undergoes regular third-party penetration testing. Here is our most recent certification. For enterprise customers needing access to the full report, please email support@trysundial.ai.
  • Google Chrome Web Store Security Review: Chrome Web Store reviews each new version of Sundial ensuring compliance with their developer program policies.

5.3 Incident Response

  • Monitoring & Response: Security vulnerabilities are proactively addressed.
  • User Reporting: Contact support@trysundial.ai for security concerns.
  • Breach Protocol: Immediate notification and remediation if a breach occurs.

5.4 Data Protection Agreement (DPA)

Sundial maintains a standard DPA here. We can do custom DPAs with Enterprise customers.

6. Security Governance

6.1 Subprocessors

Sundial uses the following subprocessors to deliver its services. All vendors are reviewed for security and compliance:

  • Google Cloud Platform – Hosting, storage (Firestore), OAuth token handling, Calendar API (us-central1)
  • Render – Hosted backend relaying API requests to OpenAI. No data is stored. (Oregon)
  • OpenAI – User-initiated AI processing of scheduling text (e.g. extracting dates/times) (US distributed)
  • Netlify – Frontend hosting of the dashboard (us-east-1)
  • Stripe – Payment processing (US distributed)
  • Mailgun – Transactional emails (e.g. invites) (US distributed)

For subprocessor-related inquiries or to request notifications of changes, contact support@trysundial.ai.

6.2 Internal Access & Development Controls

  • Access Reviews: Periodic reviews of system access permissions.
  • Secure Development Lifecycle (SDLC): All code changes are reviewed prior to deployment.
  • Employee Device Security: Devices are encrypted and secured with strong authentication.

7. Business Continuity & Disaster Recovery

  • Service Status: Live uptime and incident history available here.
  • Data Resiliency: All infrastructure hosted on Google Cloud with built-in redundancy.
  • Business Continuity: Sundial maintains contingency plans to ensure ongoing service availability.