An honest account of how we protect your plans.
Here is what is actually in place today, who processes data on our behalf, and what is still on the roadmap. We tell you what we can prove — and mark what's planned as planned.
You choose where your plans live
SimplyCount runs on-premise/offline or in our hosted cloud — your choice. When you run it on-premise, your plan sets are processed on your own device or inside your own network and are never uploaded to us. The measures below describe the hosted service and our web properties; on-premise deployments are governed by your own environment's security.
Security measures in place today
These are implemented and running now, not aspirational:
Encryption in transit In place
All traffic to our services is served over TLS, with HTTP Strict Transport Security (HSTS) enforced.
Secret management In place
Application secrets (admin and integration keys) are stored in Google Secret Manager and mounted at deploy — never committed to code or kept as plaintext config.
Least-privilege service accounts In place
Each service runs under its own dedicated service account with only the permissions it needs. The marketing site has no access to CRM or secret material.
Real, revocable sessions In place
Admin access uses opaque, server-side session identifiers with a 12-hour idle and 30-day absolute timeout, plus per-session revocation. Raw tokens are never used as cookie values.
CSRF protection In place
State-changing admin actions are protected against cross-site request forgery.
Rate limiting In place
Public write endpoints (analytics and lead capture) are rate-limited per client to bound abuse and fabricated traffic.
Salted-hash PII crosswalk In place
Where we correlate records internally, identifiers are matched through a salted hash rather than by storing raw personal identifiers in the join.
Hardened HTTP headers In place
Responses set a Content-Security-Policy, X-Frame-Options (deny framing), X-Content-Type-Options, and a strict referrer policy.
Attributed audit logging In place
Administrative actions are recorded in an append-only audit log; actions taken via verified Google sign-in are attributed to a specific person.
Access-scoped admin auth In place
The product-owner console is gated behind Google sign-in restricted to allowed domains, or a revocable redemption link — not an open endpoint.
Planned and in progress
We are honest about the gap between where we are and where we're going. These are not yet in place:
Automated data-retention purge Planned
Today our retention policy is applied as a read-time filter — older records are excluded from views. A background purge job that actually deletes past-retention data is planned but not yet built. See the retention section below.
Per-collection data isolation Planned
Database access is currently scoped at the database level. Finer-grained per-collection isolation between services is planned.
Full least-privilege migration In progress
Our primary services run under dedicated least-privilege service accounts; a few auxiliary services are still being migrated off a broader shared account.
Formal compliance program Planned
We do not hold SOC 2 / ISO 27001 today. A formal program and third-party assessment are goals for the future, not current status.
Subprocessors
We use a small set of vendors to operate the hosted service. Each processes only the limited data needed for its function, under its own terms.
| Subprocessor | Purpose | Data involved |
|---|---|---|
| Stripe | Payments & subscription billing | Billing details, payment card data (handled by Stripe; not stored by us) |
| Keygen | Software licensing & key verification | License keys, activation/entitlement data |
| Google Cloud | Hosting & infrastructure | Hosted application data, logs, database |
| Resend | Transactional email delivery | Recipient email address, message content |
| Assembly | Customer relationship management (CRM) | Contact and account details, sales/support correspondence |
This list reflects the current stack and may change; we will keep it current here. To be notified of material subprocessor changes, contact us below.
Data handling & retention
You own your Customer Data (your plan sets and the counts produced from them). We process it only to provide the Service, and we do not sell it or use it to train shared or third-party models.
Retention, stated honestly: our retention policy is currently enforced as a read-time filter — records past the retention window are excluded from views and reporting. An automated purge job that permanently deletes past-retention data is planned but not yet implemented. We do not claim automated deletion we haven't built. If you need data deleted now, email us and we will handle it manually.
Report a vulnerability
We welcome responsible disclosure. If you believe you've found a security vulnerability in SimplyCount, please tell us before disclosing it publicly, and give us a reasonable window to investigate and fix it.
Email infrastructure@simplycount.com with steps to reproduce, the affected URL or component, and its impact. We will acknowledge your report, keep you updated, and credit you if you'd like.
Please do: test only against your own account and data, and avoid privacy violations, data destruction, or service disruption. Please don't: run automated scanning at scale or access other customers' data. We currently run an informal program; a formal policy and, in time, a coordinated-disclosure page are planned.
Questions
Security or privacy questions, subprocessor notifications, or a data request: infrastructure@simplycount.com. See also our Privacy Policy and legal documents (all drafts pending counsel review).
A number you can defend — and a company that levels with you.
Run your own plans and see exactly what SimplyCount marks. On-prem or cloud, your choice.