AssertionJoin the pilotJoin pilot

Security & privacy

How we handle your data.

This page describes how we handle customer data today, with the full text of each policy underneath.

Last updated · July 21, 2026 · security@assertion.so

Data

The data we handle.

Assertion works with the records accounting teams already produce – general ledger and subledger extracts, supporting schedules, reconciliation detail, and the policies that govern them. We don't process payments and we don't touch consumer data: our users are accounting teams, and the data stays theirs.

During pilots we ask for the minimum dataset a workflow needs – a scoped extract rather than a standing integration.

Policy – full textData handling & retention
  1. “Customer data” means any information a customer provides to Assertion or that Assertion accesses on a customer's behalf – ledger extracts, schedules, supporting documents, and the outputs derived from them.
  2. All customer data is classified confidential by default and handled under this policy regardless of format or where it's stored.
  3. We collect the minimum data required for the agreed work. Pilot engagements begin from scoped extracts rather than standing integrations unless the customer asks otherwise.
  4. Customer data is stored only in Assertion's production systems, on AWS in United States regions. It is not stored on personal devices or removable media; company laptops use full-disk encryption.
  5. Customer data is used solely to provide and support the service. We do not sell it, rent it, or use it to train models (see the AI & model provider policy).
  6. Customer data is shared only with the subprocessors listed on this page, and only as needed to provide the service.
  7. We retain customer data for the duration of the engagement. Within 30 days of a written request or the end of a pilot, we delete it and confirm the deletion in writing.
  8. Backup copies age out on their normal rotation, within 30 days of primary deletion.
  9. The founders own this policy and review it at least annually.

Infrastructure

Where your data lives.

Assertion runs on Amazon Web Services, in United States regions only. Data is encrypted in transit and at rest, production is separated from development, and development environments never hold customer data.

Policy – full textInfrastructure & continuity
  1. All production infrastructure runs on AWS, in United States regions.
  2. Data is encrypted in transit using TLS 1.2 or higher, and at rest using AES-256.
  3. Production and development are separate environments with separate credentials. Development and test run on synthetic data, never customer data.
  4. Production databases are backed up automatically at least daily; backups are encrypted and retained for at least 30 days.
  5. We test restoring from backup at least quarterly.
  6. Infrastructure changes go through the same review as code changes.
  7. Access to production infrastructure is governed by the Access control policy.

AI

AI and your data.

Workflow runs use large language models to plan and orchestrate the work; numeric computation is done by deterministic operations. When your data reaches a model, it goes to the providers below, under API or business terms that exclude training on your data.

We use Anthropic, OpenAI, and Google models for inference, and Voyage AI for embeddings – all through API or business tiers whose terms exclude using your data to train their models. Assertion does not use customer data to train models; the only exception the policy allows is your explicit written consent.

Policy – full textAI & model providers
  1. Assertion uses the following model providers: Anthropic, OpenAI, and Google for model inference, and Voyage AI for embeddings. Each is listed as a subprocessor on this page.
  2. We use these providers only through API or business tiers whose terms exclude the use of customer inputs and outputs for training the provider's models.
  3. Where a provider offers configurable data-retention controls, we enable the strictest setting available.
  4. Assertion does not use customer data to train, fine-tune, or evaluate models – ours or anyone else's – without the customer's explicit written consent.
  5. Each workflow step sends a model the minimum context that step needs, not the full dataset.
  6. Numeric computation is performed by deterministic operations rather than model inference. Model-orchestrated steps record lineage, so outputs can be traced and reviewed.
  7. We add a new AI provider only after reviewing its data terms, updating the subprocessor list, and – where it would process an existing pilot customer's data – notifying that customer first.
  8. The founders own this policy and review it at least annually.

Access

Who has access.

Inside Assertion, access follows least privilege: multi-factor authentication on every console, unique named accounts, and same-day revocation when someone leaves. Pilot workspaces are provisioned by us as named individual accounts; single sign-on and customer-facing MFA are planned before general availability.

Policy – full textAccess control
  1. Access to systems holding customer data is granted per system, on need, at the minimum level required.
  2. Multi-factor authentication is required on all infrastructure and administrative consoles – cloud, code hosting, and workspace accounts.
  3. Every account is a unique named account. Shared credentials are prohibited. Passwords are generated and stored in a password manager and are unique per system.
  4. Access to production customer data is limited to the founders and named engineers who require it, and is logged where the platform supports it.
  5. When a team member departs, all access is revoked the same day.
  6. We review who has access to what at least quarterly, and remove anything no longer needed.
  7. Customer pilot workspaces use named individual accounts provisioned per user. Single sign-on and customer-facing multi-factor authentication are on the pre-GA roadmap.
  8. The founders own this policy and review it at least annually.

Development

How code reaches production.

Changes reach production through review. Code is reviewed before merge, dependencies are scanned continuously, secrets live in a secrets manager – never in the codebase – and development happens on synthetic data.

Policy – full textSecure development
  1. Changes to production code are reviewed before merge.
  2. Automated dependency scanning runs on our repositories. Critical vulnerabilities are patched within 7 days; high-severity within 30.
  3. Secrets and credentials are stored in a managed secret store, never committed to source control, and rotated immediately on any suspicion of exposure.
  4. Development and testing use synthetic or fixture data. Customer data is not copied into development environments.
  5. Features that touch customer data get a security review at design time.
  6. The founders own this policy and review it at least annually.

Incidents

When something goes wrong.

Suspected incidents are triaged immediately. If your data is affected, we notify you without undue delay – target within 72 hours of confirmation – and update you as facts develop.

Found a vulnerability? Email security@assertion.so. We don't run a paid bug bounty yet – we do read every report, respond within three business days, and credit researchers who want it.

Policy – full textIncident response plan
  1. An incident is any suspected or confirmed unauthorized access to, disclosure of, loss of, or alteration of customer data – or a compromise that materially affects the service.
  2. Anyone at Assertion who suspects an incident escalates to the founders immediately upon discovery.
  3. First response: contain the issue, preserve evidence, and establish scope – what data, which customers, what window.
  4. If a customer's data is affected, we notify that customer without undue delay – target within 72 hours of confirmation – with what we know, the impact, and what we're doing about it. We update as facts develop rather than waiting for a complete picture.
  5. We assess and meet applicable legal and regulatory notification obligations as part of the response.
  6. Within 14 days of resolution we write a post-incident review; corrective actions are tracked to completion.
  7. External security reports to security@assertion.so are acknowledged within 3 business days. We do not pursue legal action against good-faith, non-destructive security research.
  8. The founders own this plan, review it at least annually, and walk through it once a year even if no incident has occurred.

Subprocessors

Third parties that handle your data.

Every third party that processes customer product data, and why. We notify pilot customers before adding a subprocessor that would process their data.

VendorPurposeLocation
Amazon Web ServicesCloud hosting, storage, backupsUnited States
AnthropicModel inferenceUnited States
OpenAIModel inferenceUnited States
GoogleModel inferenceUnited States
Voyage AIEmbeddingsUnited States

This website sets no analytics or tracking scripts. The pilot form collects your name, work email, company, role, and what you tell us about your close; a form-processing service delivers it to our inbox, and we use it only to evaluate and respond to your request.

Roadmap

What's planned.

SOC 2 is on the roadmap; the audit will cover the practices described on this page. A standard data processing agreement will be available before general availability. If you're evaluating Assertion and need answers this page doesn't cover, write to security@assertion.so.

Early pilot

We're onboarding a handful of early teams.

Tell us where your close hurts. That answer doesn't go to a sales queue – it goes to the founders who write the roadmap. Pilot teams get early access, and first say in what we build next.