Security & data handling

There is no server in the path of your course files, because there is no server StoryAudit sends them to.

Client-side, by architecture, not by policy

When you open a .story file in StoryAudit, the file is read and parsed entirely inside your browser tab, using the browser's own File API. There is no upload step, because there is nothing to send it to: StoryAudit doesn't have a backend that accepts course files. The parsing, the health checks, the quiz answer extraction, the version comparison, all of it runs as JavaScript executing locally on your machine, the same way a spreadsheet app parses a file you open from disk.

It's the only way the tool works. There's no server-side code path for course content to travel through, so there's nothing to misconfigure, no upload log to secure, and no third party in the chain who could see the file even if they wanted to.

What never happens

• Your .story file is never uploaded. It's read from disk into browser memory and never transmitted anywhere.
• Nothing is stored on a server. There's no database of course content, because there's no server-side storage layer handling course content at all.
• Reports and run history stay in your browser. To make repeat audits faster, the app keeps a cache of recent reports and a local run history in your browser's own storage (IndexedDB). On a Team plan, run history also syncs (see below). See the privacy policy for exactly what's stored and how to clear it.
• No course content is used for analytics, training, or any other purpose. There's no pipeline for that, because the content never reaches infrastructure that could do it. The app does keep anonymous daily counts of app opens, tabs viewed, files loaded and export buttons pressed (the tool and what happened only, with no account, file name or content attached) so we can see which features people use; see the privacy policy.

What's different on a Team plan

Everything above still holds: your .story files are never uploaded, on any plan. Team plans add one thing that isn't course content: to share review decisions across a team, waivers (which findings were cleared, by whom, and why), run history, and basic team membership (names, invite codes, roles) sync through StoryAudit's servers, hosted on Vercel with a Postgres database (Neon) and Clerk for authentication. None of that data includes the course file itself or its contents, only records about who reviewed what and when.

Subprocessors and what each one holds

• Clerk (United States): sign-in and subscription billing. Holds name, email, sign-in sessions and subscription status. StoryAudit never receives full card numbers.
• Stripe (United States): processes card payments for Clerk's billing. Holds card details and billing contact information.
• Vercel (United States): hosts the site and the app and runs the team API. Keeps standard access logs (IP address, browser type).
• Neon (United States): the Postgres database for Team workspace data (team name and members, waived findings, rule sets, run history, sign-off records) and the anonymous daily usage counts.
• Google: Google Fonts serves the site's display typeface. Google Ads conversion measurement runs on the marketing pages. The app itself carries no Google tag.

How long data is kept

• Account and billing records: while the account is active, plus a reasonable period afterward for legal and tax purposes.
• Team workspace data: as long as the team exists. Deleting the team deletes it, and individual records are deleted on request.
• Hosting access logs: only for the short periods Vercel keeps them.
• Report cache and local run history: on your device until you clear them.

Reporting a security issue

Email support@storyaudit.app with "Security" in the subject. If an incident affects your organization's data, we notify you without undue delay, as the DPA describes.

DPA, security overview and accessibility

For procurement or legal review, the documents below describe this architecture formally and can be shared with your security or privacy team as-is. The accessibility conformance report covers WCAG 2.0, 2.1 and 2.2 Level A and AA, based on VPAT 2.5.

The DPA above is a draft, written as an accurate starting point for your reviewer. If your organization needs an executed DPA, email support@storyaudit.app to start that process. See also the privacy policy for the full explanation of what data StoryAudit does and doesn't handle, including account and billing information (handled by our payment processor) and, for Team plans, the review-decision sync described above (Vercel, Neon, Clerk).

Common procurement questions

• Does StoryAudit need network access to work? No. Once the page has loaded, opening and analyzing a .story file works with no network requests for the file itself. (Loading the page, checking for app updates, license validation, and the anonymous usage counts described above do use the network. A usage count carries only the tool and what happened.)
• Can StoryAudit see the contents of our courses? No. There's no path for course content to reach us; it's processed entirely in the browser session that opened it.
• Where does the .story file go after I close the tab? Nowhere. It was never sent anywhere to begin with. The in-memory working copy used during analysis is discarded when the tab closes. A report cache and run history stay in your browser's own storage so repeat audits are faster, and you can clear both at any time. The report cache is never transmitted. On a Team plan, run history also syncs to your team's workspace: file names, dates and finding counts, never the file or its contents. See the privacy policy.
• Is this covered by a signed agreement, not just a webpage? Not yet. The DPA above is a draft, so a reviewer can read the actual terms before requesting a signed copy. Email support@storyaudit.app to get a signed DPA in place.
• Is there an SLA? A 99.9% monthly uptime commitment with a service-credits addendum can be negotiated on the Enterprise plan. Email support@storyaudit.app to start that conversation.

↑ Back to top