Information Security Policy

1. Purpose and scope

This Information Security Policy describes the administrative, technical, and organizational controls Ascenditt Digital Marketing uses to protect systems and data for the Sendtonium Klaviyo audit application at app.sendtonium.com. It applies to employees, contractors, and administrators who access production systems, customer data, or secrets.

This document is separate from our Privacy Policy, which explains how we collect and use personal information. This policy explains how we secure the systems that store that information.

2. Roles and responsibilities

• Leadership owns this policy, approves access to production, and is accountable for incident response.
• System administrators configure hosting, databases, identity providers, and secrets. They follow least privilege and review access regularly.
• All personnel must use unique accounts, protect credentials, enable required device controls, and report suspected incidents immediately.

Security questions: hello@sendtonium.com.

3. Data classification and handling

Ascenditt Digital Marketing classifies information by the harm that unauthorized disclosure, alteration, or loss could cause. When information fits more than one class, the stricter class controls apply.

Personnel must not move Confidential or Restricted data to a lower-control system. Suspected misclassification or exposure is reported through the incident process.

4. Access management

• Production access is limited to named personnel with a business need. Shared passwords for production consoles are not permitted.
• The Sendtonium admin portal is restricted to an allowlisted set of administrator emails. Unlisted accounts cannot use admin tools even if they can authenticate.
• Customer accounts only see their own audit data. Server-side authorization and database access controls prevent customers from reading other customers' records.
• Privileged credentials (database service role, OAuth client secrets, encryption keys, API keys) are stored in the hosting provider's secret store / environment configuration, not in source code. Access to those stores is limited to administrators.
• Access is revoked when a person leaves the company or no longer needs production access. Keys and tokens are rotated after suspected compromise.
• Administrators must enable multi-factor authentication on cloud consoles that support it (hosting, database, source control, Google Cloud, and similar vendors).

5. Encryption

• In transit: All public application traffic uses HTTPS with TLS 1.2 or higher. API calls to Klaviyo, our database, and other vendors use encrypted connections.
• At rest (application): Klaviyo OAuth access and refresh tokens are encrypted with AES-256-GCM before they are stored. Encryption keys are not committed to the repository.
• At rest (infrastructure): Customer data lives in managed cloud database and object storage provided by our hosting vendors, which encrypt data at rest using industry-standard algorithms.
• Secrets: OAuth client credentials and other secrets are retrieved from the environment at runtime. They are not hardcoded in application source.

6. Device and endpoint controls

Any company-issued or personally used workstation that accesses production systems, customer data, or secrets must have the following controls enabled:

• Endpoint (full-disk) encryption using the platform native tool (FileVault on macOS, BitLocker on Windows, or LUKS/equivalent on Linux).
• Host firewall enabled using the platform native firewall (macOS Application Firewall, Windows Defender Firewall, or equivalent).
• Automatic operating system and browser security updates.
• Screen lock with a password, PIN, or biometric unlock when the device is idle.
• Unique user accounts. Production secrets must not be stored in unencrypted files or chat.

Personnel who cannot enable these controls must not access production. Leadership is responsible for confirming these controls on devices used to administer Sendtonium.

7. Application and network security

• Public pages and APIs are served over HTTPS. The production application is hosted on Vercel. The primary datastore is Supabase (Postgres) with row-level security enabled.
• Backend jobs that need elevated database access use a server-only service role that is never exposed to the browser.
• Customer OAuth tokens are never used as the application's login session. App login is separate from the Klaviyo connection.
• The Klaviyo integration requests read-only scopes only. The application does not write campaigns, flows, or profiles back to Klaviyo.
• Input used in server actions and APIs is validated. Errors returned to clients are written so they do not leak secrets.

8. Vulnerability management

• Application dependencies are tracked in the repository lockfile and updated when security patches are available for libraries we use.
• Critical or high vulnerabilities in third-party libraries used in production should be remediated on an accelerated timeline (target: 3 days for critical, 7 days for high, consistent with our marketplace security expectations).
• Production deploys come from the git main branch via the hosting provider. Changes are reviewed before they are merged when more than one engineer is available.
• We do not run known-vulnerable versions of Chromium, Node, or other runtime components on production when a patched release is available from the vendor.

9. Logging, monitoring, and retention of logs

• Application errors and operational events are logged by the hosting platform and our structured error logger. Logs are used to detect failures, abuse, and security incidents.
• Security-relevant logs (authentication failures, privileged API use, and application errors) are retained for at least 365 days where the platform allows.
• Logs must not be used as a substitute for storing secrets in a secrets manager.

10. Incident response

An information security incident includes suspected unauthorized access to customer data, secrets, or production systems; malware on an admin device; or a vendor breach that may affect Sendtonium.

1. Detect and report. Personnel report incidents immediately to leadership at hello@sendtonium.com (or by phone if email is unavailable).
2. Contain. Revoke compromised credentials, rotate keys, disable affected accounts, and isolate devices as needed.
3. Investigate. Determine scope (systems, data categories, time window) using logs and vendor notices.
4. Notify. Affected customers and, where required, regulators or partners (including Klaviyo if the integration is involved) are notified without unreasonable delay.
5. Recover and learn. Restore service from known-good configuration, document root cause, and update this policy or controls if gaps are found.

11. Backup, disaster recovery, and business continuity

• Application: Source of truth is git. The production app can be redeployed from the main branch if a hosting region or deployment fails.
• Database frequency and retention: The production database is on Supabase's Pro plan. Supabase creates one managed database backup every day and retains the seven most recent daily backups. Point-in-time recovery is not currently enabled. A restore can therefore return the database to the latest daily recovery point, with a target recovery point objective (RPO), or expected maximum database data loss, of 24 hours.
• Object storage: The current Supabase managed database backup does not include Storage objects; it backs up their database metadata only. Supabase does not provide a separate retained backup of objects on the current plan. We therefore use object storage only for generated report and deck images, not as the authoritative store for customer records. If those objects are lost, they are regenerated from retained audit data and, where needed, the customer's authorized Klaviyo source data. Loss of the bucket could require regeneration of all generated assets, but does not increase the 24-hour RPO for authoritative database records.
• Continuity: If a primary vendor is unavailable, we communicate status to affected customers, pause new OAuth installs if we cannot process them safely, and fail closed on report access rather than serving another customer's data.
• Recovery time objective: We target restoration of core application and database service within 24 hours of an incident beginning. This includes up to four hours to detect and assess the outage, up to two additional hours to decide on and initiate recovery, and up to 18 additional hours for vendor restoration, application redeployment, validation, and DNS or cache recovery. Generated report images may continue regenerating after core service is restored.
• Restore testing: At least quarterly, we test the recovery runbook by redeploying the application from source, validating access to an available database backup, restoring a representative database export into a non-production environment, and regenerating representative report assets. Results and corrective actions are documented. We also review the runbook after a material architecture change or incident.

12. Vendors and subprocessors

We use subprocessors to host and operate Sendtonium, including application hosting, database and authentication, object storage, email delivery, AI processing, and (for decks) Google APIs. Customer Klaviyo data is processed only as needed to run audits and produce reports.

Before onboarding: We assign a risk level based on the data class the vendor will receive, whether it hosts production or Restricted credentials, the volume of data, and the service's operational criticality. For vendors handling Confidential or Restricted data, we review available SOC 2, ISO 27001, penetration testing, or equivalent assurance; encryption in transit and at rest; identity, least-privilege, and MFA capabilities; vulnerability and incident-response practices; backup and continuity commitments; breach-notification terms; data locations, retention and deletion; privacy terms / DPA; subprocessor disclosures; and relevant service history. Material gaps must be remediated, contractually accepted by leadership, or the vendor is not approved.

Ongoing review: Critical vendors and vendors processing Confidential or Restricted data are reviewed at least annually, and sooner after a reported incident, material service or subprocessor change, contract renewal, or significant change in the data we send. Reviews check current assurance reports, security and privacy notices, access permissions, incidents, availability, and whether the vendor remains necessary. Findings and risk-acceptance decisions are documented. Access is removed and data is deleted or returned when a vendor is offboarded.

13. Secure development

• Production secrets are not committed to git.
• Authorization checks live on the server for admin, report sharing, and OAuth callbacks. Missing or invalid tokens fail closed (no access).
• External graders and browser automation fail soft so a vendor outage does not corrupt existing customer records.

14. Policy review

This policy is reviewed at least annually, and after a material incident or architecture change. The published date at the top of this page is the current version.