Trust Center

Security & Trust at EveryCent

Your books run on EveryCent. Here's how we protect them.

EveryCent is built for small-business financial data — so security is engineered in, monitored continuously, and verified independently. This page is generated from our live compliance system, not a marketing document.

All systems operational ✓ SOC 2 Type 1 AES-256 encryption Google Cloud 23 controls monitored live

Independent verification

Third-party and continuously-monitored signals you can verify yourself.

SOC 2 Type 1 attestation — Security, Availability & Confidentiality — as of June 1, 2026

Independently examined by Atom Assurances LLC, Certified Public Accountant Firm. The full report is available to prospects and customers under NDA — request it below.

Run the live test ↗ SSL/TLS · Qualys SSL Labs
20/23 controls passing (live)
August 6, 2026 last verified restore drill

Doing a security review of EveryCent?

Send us your questionnaire (SIG, CAIQ, or your own) — our Trust team answers from our live controls, typically within one business day.

Start a security review →
💬

Ask about EveryCent's security

Get an instant, cited answer from our live controls and policies — no questionnaire required.

Answers cover our public security posture only. Need a full SIG / CAIQ completed? Contact security@everycent.ai →

Our controls

23 active controls, monitored continuously and grouped by area. Expand any category to see what we enforce.

Data Protection & Access Control
Encryption, least-privilege access, and the controls that keep customer financial data private.
6
No service-account keys exist
Zero user-managed service-account keys exist in the production project and the iam.disableServiceAccountKeyCreation org policy is enforced
Runtime service account matches least-privilege baseline
The Cloud Run runtime service account holds exactly the approved baseline roles {roles/cloudsql.client, roles/run.invoker, roles/cloudsql.viewer, roles/logging.viewer, roles/iam.securityReviewer} and nothing broader. The three viewer roles were added 2026-06-11 as read-only grants for the compliance collectors (documented expansion, not drift).
Cloud SQL is private-IP only
The production Cloud SQL instance has no public IP; connectivity is via private IP / VPC only
GCS public-access prevention + uniform bucket-level access
All production GCS buckets have public-access-prevention enforced and uniform bucket-level access enabled
MFA enabled on all 10 critical systems
Multi-factor authentication is verified enabled on the critical systems: Google Workspace/GCP (also backs Google Password Manager), Apple ID (backs Apple Keychain), GitHub (everycentai org), Namecheap (registrar + DNS), Plaid (banking), Stripe (payments), Gusto (payroll), Anthropic (AI), Resend (email), Sentry (monitoring). Credential vaults are Apple Keychain + Google Password Manager — both secured by the Apple ID / Google account 2FA above, not separate master passwords.
Quarterly access review completed
A quarterly review of all human and service access across critical systems is completed and documented (additions, removals, role appropriateness)
Infrastructure, Availability & Recovery
Hosting, backups, point-in-time recovery, and restore drills that keep your books available and recoverable.
6
Daily Cloud SQL backup succeeded
Most recent automated backup run is SUCCESSFUL and within the last 26 hours
Point-in-time recovery enabled on Cloud SQL
PITR is enabled on the production Cloud SQL instance with 7-day WAL retention
DR backup-restore drill within last 12 months
A documented disaster-recovery drill (backup restore to a scratch instance, data verified) has been performed within the last 12 months; latest drill record dated 2026-06-11
Log retention >= 365 days on Cloud Logging
The Cloud Logging _Default bucket retention is set to at least 365 days so audit-relevant logs survive a full review period
Uptime / status monitoring active
External uptime monitoring of the production endpoint is active and alerting the founder on downtime
Single-zone HA caveat documented
The accepted-risk decision to run Cloud SQL single-zone (no regional HA) is documented with rationale and revisit criteria
Change Management & Secure SDLC
Every code change passes security gates before it reaches production.
5
Branch protection on main with required checks
GitHub branch protection is enforced on main with required status checks: tests, SAST, gitleaks, dependency audit; direct pushes blocked
Nightly dependency CVE scan green
The nightly scheduled dependency vulnerability scan (mix deps.audit) completed and reported no unaddressed critical/high CVEs
Production deploys trace to merged green PRs
Every production deploy maps to a merged pull request whose required checks passed; no out-of-band deploys
Secrets scan in CI
gitleaks secrets scanning runs in CI on every push and the latest run is green
SDLC / change-management policy reviewed annually
The SDLC and change-management policy has been reviewed, updated as needed, and re-approved within the last 12 months
Governance, Monitoring & Response
Policies, risk management, vendor oversight, penetration testing, and incident response.
6
All 22 policies signed and inside review window
All 22 information-security policies are signed by the founder and within their annual review window
Risk register reviewed quarterly
The risk register (24 risks, including R-24 fraud) has been reviewed in the last quarter with likelihood/impact scores and treatments re-confirmed
Independent penetration test within 12 months
An independent third-party penetration test report is on file and dated within the last 12 months, with findings tracked to remediation
Incident register current with no-incidents attestation
The security-incident register is current; weekly review records either new incidents with response status or an explicit no-incidents attestation
Vendor SOC 2 reviews current
The vendor risk register is healthy: every critical/high vendor has an unexpired SOC 2 (or equivalent) report on file and no vendor's annual review is overdue — verified daily against the live register
Security awareness training — founder annual self-acknowledgment
The founder has completed annual security-awareness training and recorded a dated self-acknowledgment

Third-party services that may process EveryCent customer data, and what they are used for. Each is tracked in our vendor risk register with an annual review.

Anthropic transaction descriptions, document text for AI
Google Cloud Platform all customer data — infrastructure
Plaid bank credentials + transactions
GitHub source code
Stripe payment data
Gusto payroll / OAuth
Sentry error traces (PII-scrubbed)
Teller bank sandbox
PostHog anonymized analytics
Resend transactional email

Documents

Public documents download directly; NDA-gated material is shared after a quick access request.

Data Processing Addendum
Available on request while the self-serve copy is being finalized.
Security whitepaper
Available on request while the self-serve copy is being finalized.
SOC 2 report
SOC 2 Type I in progress with Atom Assurances LLC — expected after fieldwork.
Penetration test summary
First independent penetration test is being scheduled.

Access requests are reviewed quickly; granted links are one-time, expiring, and audit-logged.

Frequently asked questions

The questions security reviewers ask us most often.

Where is EveryCent data stored?

All customer data is stored in the United States on Google Cloud Platform (region us-central1). We do not replicate customer data outside the US.

How is data encrypted?

Data is encrypted with AES-256 at rest across our Google Cloud infrastructure and TLS 1.2+ in transit. Credentials and sensitive personal data get an additional layer of application-level field-level AES-256-GCM encryption.

What is your data retention & deletion policy?

Customer data is retained for the life of the account and deleted in accordance with our Data Processing Addendum (DPA) after termination, subject to legal and tax retention obligations. You can request export or deletion at any time by emailing security@everycent.ai.

How and when are security incidents disclosed?

Our incident response policy commits to notifying affected customers without undue delay and within 72 hours of confirming a reportable security incident, with follow-up updates as our investigation progresses.

Who are your subprocessors, and will I be notified of changes?

Our current subprocessors are listed on this page, each tracked in our vendor risk register with an annual review. You can subscribe to subprocessor change notifications using the link in the Subprocessors section.

Do you offer an API and a status page?

Yes. EveryCent has a documented REST API (Bearer-token auth, rate-limited, with signed webhooks) and continuously monitors uptime. Reach us at security@everycent.ai for status or API access questions.

Security questions, responsible disclosure, or questionnaire requests: security@everycent.ai

This page is generated live from EveryCent's compliance system.