Assess Integrate Automate
Legal

Security

Version 1 · Effective 9 August 2026

Everything on this page is something we actually do. Where we do not have something, it says so. A security page that overstates is worse than no security page, because the day it matters, every sentence on it gets read back to you.

The design decision that does the most work

The safest data is the data you never hold. Our software reads students, families, classes and schedules. It does not read transactions, balances, payment history, or a studio's books — not because we could not, but because nothing we build needs them.

That single choice removes card data, bank details, and financial history from our systems entirely. It keeps us out of PCI scope. And it means the worst possible day here does not involve anyone's money.

Access to your own software

When a studio connects the system they already use, they do it by creating a login inside their platform, with whatever permissions they are comfortable granting. The consequences of that are all in their favor:

How those credentials are stored

The audit trail

Changes to studios, students, families, credentials and orders are recorded in an append-only log: what changed, which fields moved, what the previous value was, who did it, and when. It is scoped to each studio, so a studio sees its own history and nobody else's.

The log has no edit or delete path in the application — including for us. Entries are written by the database itself, not by code that could be talked into skipping them. That is the point: a trail you can quietly amend is not a trail.

Isolation between studios

Separation is enforced by the database, not by the application. Every record carries the studio it belongs to, and the database refuses to return another studio's rows even if the application asks incorrectly. Application bugs are inevitable; this is the floor underneath them.

Encryption

Backups and getting your data back

Our own access

Support access is limited to what is needed to answer the question in front of us, and it is logged like any other change. We do not browse customer data for curiosity, product ideas, or marketing lists. Administrative access is protected by multi-factor authentication.

Payments

Card processing is handled entirely by Stripe, a PCI-DSS Level 1 service provider. Card numbers go from the cardholder to Stripe and are never transmitted through, processed by, or stored on our systems. We can see that a payment succeeded; we cannot see the card.

What we do not claim

Plenty of vendors imply certifications they do not hold. Here is our honest list:

  • We are not SOC 2 certified. If that changes, this page changes.
  • We are not ISO 27001 certified.
  • We are not HIPAA-compliant and must not be sent health information.
  • We do not offer a contractual uptime guarantee. We will not promise a number we cannot back with a credit.
  • We have not had a third-party penetration test. When we do, it will be named here with its date.

Our infrastructure providers do hold SOC 2 and ISO certifications for the layers they operate — but those are their certifications, and we will not dress them up as ours.

If something goes wrong

Affected studios are notified within 72 hours of us confirming an exposure, with what happened, what data was involved, what we have done, and what they should do. Then a written follow-up once we know the full picture.

Telling us about a problem

If you find a vulnerability, email hello@successfuldancestudiosystems.com with enough detail to reproduce it. We will confirm receipt within two business days and keep you posted. We will not pursue anyone who reports a genuine issue in good faith and does not access or alter other people's data while finding it.

The short version We never hold card numbers or a studio's books. Credentials can be saved but never read back. Every change is logged and the log cannot be edited. Studios are separated by the database itself. And we do not claim a single certification we have not earned.