Privacy Policy

Last updated: July 2026. SwiftSCORM is operated by BWS Holdings LLC (Fort Smith, Arkansas). This policy is written in plain language on purpose; it is the policy, not a summary of a longer one.

Your documents

When you upload a file to generate a course, its text is sent to our AI provider (Anthropic) to write questions and returned to your browser. We do not store your uploaded documents on SwiftSCORM servers, and your documents are not used to train AI models by default. Our processors have their own retention: under Anthropic's commercial API policies, inputs and outputs may be retained by Anthropic for a limited period (up to 30 days under their standard policy) for trust and safety, and are not used to train their models by default. Packages you export are assembled in your browser and downloaded directly to your device.

Media transcription

If you upload an audio or video file, it is sent to our transcription provider (OpenAI) to produce a transcript, which then feeds the same course flow. We do not keep the media on SwiftSCORM servers after transcription; OpenAI processes it under its own API data-usage policies for the transcription endpoint. If you connect Zoom, we use your authorization to fetch the recording or transcript you select; a short-lived cookie protects the sign-in handshake.

Do not upload PHI

SwiftSCORM offers HIPAA training content, but SwiftSCORM itself is not a HIPAA-ready processing environment: we do not sign Business Associate Agreements and have not configured our AI providers for PHI. Do not upload documents or media containing protected health information or patient records. Train your team on HIPAA with our materials; keep actual PHI out of the product.

Hosted courses and learner records

If you publish a course for link delivery, we store what the product exists to prove: the course content you published and each learner's completion record (score, pass/fail, date, certificate). A learner's roster card can hold the fields the employer chooses to enter: name, email, job title, worksite/location, management level, phone number, preferred language, assigned role, status, and free-text notes. We also keep reminder and notification records (what was sent, to whom, when) and SMS consent and opt-out records, because those are compliance evidence. We process learner records as a service provider to the employer or trainer who published the course, and we keep them so that your audit trail persists. Course owners can request deletion of a course and its records at any time (see Your rights below).

Billing

Payments are processed by Stripe. Your card number never touches our servers. To grant access and send receipts we store your plan, billing status, the email you used at checkout, your Stripe customer and subscription identifiers, and the identifier of the last billing event we processed. Stripe retains its own transaction records under its privacy policy.

SMS nudges

If an employer enables SMS reminders for a learner who consented, messages are sent through Twilio to the phone number on the roster card. We store the consent record and any opt-out; reply STOP to any message to opt out. Twilio processes message data under its own policies.

Support and feedback

If you send feedback through the product or email support, we keep that correspondence and the category you chose so we can respond and fix things. Feedback is stored without your page address or browser details.

Helping improve our AI (optional)

By default, the quizzes you generate are not used to train our AI. If you check the optional "Help improve our AI" box while editing a quiz, we store the generated questions and your edits, never your uploaded document, to help train our own models. It is entirely optional and off unless you opt in. Template courses we provide are our own content and may be used to improve our models.

Analytics, cookies, and local storage

We use cookieless, aggregate web analytics (Vercel Web Analytics) to understand traffic. Per Vercel's published policy it records, per page view: the page path, referrer, approximate location derived from the IP address (the IP itself is discarded, not stored), browser, operating system, and device type, tied to a visitor identifier that cannot be traced across days. It runs only on our public marketing and documentation pages. It is not loaded at all on learner pages, course links, portal pages, certificate pages, the builder, your dashboard, or settings, so the addresses of those pages are never measured or sent anywhere. Where analytics does run, the address is reduced to the page path before it leaves your browser, and any query string or anchor is discarded. We do not use advertising trackers and we do not sell personal data. The free tier counts requests by IP for abuse prevention only. We also use essential cookies and browser storage to run the product, operational, not tracking: swiftscorm_session (your signed sign-in session), and when you connect Zoom, zoom_oauth_state (protects the sign-in handshake against forgery) and zoom_token (holds your temporary Zoom access authorization so we can fetch the recording you choose). Your dashboard link is kept in your own browser's storage so you can get back to it.

Third-party processors

SwiftSCORM relies on Anthropic (question generation), OpenAI (optional transcription), Stripe (payments), Resend (transactional email such as learner invites and dashboard links), Twilio (optional SMS reminders), Zoom (optional recording import you authorize), Supabase (database hosting), and Vercel (application hosting and analytics). Each processes data to provide their service under their own policies, including their own retention periods; where we say data is not stored on SwiftSCORM servers, a processor may still retain it for the period their policy states. For Stripe, Resend and Twilio, removal on their side is a manual step someone here performs and records, not something this product calls automatically, and the shape of that step differs by provider: Stripe recommends a redaction job rather than a customer delete, and will not redact a transaction until 90 days have passed; Resend has no way to delete an individual sent email, so a removal request goes to their support; Twilio can delete or redact a message but documents minimum retention for some fields. For Zoom there is nothing for us to do at all: we read a recording you select, once, and the recording stays in your own Zoom account under your own retention, which we do not administer. The policies we rely on for the claims above: Anthropic data retention, Anthropic training use, OpenAI endpoint policies, and Vercel Web Analytics privacy.

Your rights

You can ask us to access, correct, or delete the personal information we hold about you or your learners. California residents have these rights under the CCPA/CPRA, and we honor the same requests from anyone. Email hello@swiftscorm.com from the address on the account. We will confirm receipt and respond within the timelines applicable law requires; for California requests that means acknowledging within 10 business days and responding within 45 calendar days (see the California Privacy Protection Agency FAQ). We do not sell or share personal information as those terms are defined in the CCPA.

What deleting a learner actually does

We would rather tell you this than let you assume it. Deleting a learner removes their roster card, which is the record that exists to describe them. It does not destroy the employer's completion evidence, because that evidence belongs to the employer and proves training that really happened. Instead we clear the identity from it: the name and the email address on each enrollment and certificate are set to null, while the score, the dates and the pass or fail result stay. Certificates keep their verification token, so a link an inspector already holds still resolves, and it no longer names anybody. Reminder and notification records are treated the same way.

Three things are kept on purpose. An opt-out record is kept, because deleting it would let us contact the person again, which is the opposite of honouring the request. An email suppression record is kept for the same reason and holds a one-way fingerprint of the address rather than the address. And a small number of evidence rows carry an internal identifier that the database will not let us blank without destroying the evidence row itself; what remains there is a bare identifier whose roster card no longer exists.

What deleting an account actually does

Closing an account is not a single delete. Your email address is the account key in retained records, sign-in links and billing metadata, so simply removing the account row could let a later sign-up with the same address inherit old data or old access. Instead we record a permanent, minimal note that this account was retired, holding a one-way fingerprint of the address and never the address itself, move every remaining record onto a placeholder that can never be a real address, and only then remove the account. If you sign up again later with the same address, you get a genuinely new account that inherits nothing. That retirement note is kept indefinitely, because it is what makes the previous sentence true.

What we cannot promise

A row we delete is gone from the live database immediately, but our database provider keeps daily backups, and on our current plan the last 7 days of them are retained. A deleted row remains in those backups until they age out. We do not restore a backup in order to erase a record from it.

We can find a person by the keys we store: a roster identifier, an email address, a phone number. We cannot search reliably inside free text and documents. A published course, an uploaded document's generated questions, an outbound webhook payload or a support message can mention somebody without any field naming them, and no automatic rule finds those. On request we search them by hand and tell you what we found rather than reporting a clean result we cannot stand behind.

We do not perform automated deletion inside our processors. Where a processor holds something about you, removing it is either governed by that processor's own published retention or is a manual step a person here carries out and records. We will tell you which of those applies rather than implying an erasure happened everywhere at once.

Changes and contact

If this policy changes in a way that matters, we will note it here with a new date. Any data question: hello@swiftscorm.com.