Data Security and Privacy Plan
This plan describes how SJ Tech Solution LLC (“RedString,” “we”) protects Student Data and Teacher Data in RedString for Schools, the private classroom product available at schools.redstringhq.com. It applies to every school district that uses RedString for Schools and is incorporated into our Student Data Privacy Agreements. Where a signed agreement is stricter than this plan, the agreement controls.
RedString for Schools is separate from the consumer RedString website. It has its own application, database, file storage, and sign-in. It has no public boards, sharing links, profiles, community features, messaging, advertising, third-party analytics or tracking, or artificial-intelligence features.
What we collect
We collect only what a teacher and class need to run an investigation-board assignment:
- The school-issued Google Workspace email address and the Google account identifier returned by Google sign-in. We request only the
openidandemailsign-in scopes. - The user’s role (district administrator, teacher, or student) and school and class membership.
- Class rosters and invitations entered by a district administrator or teacher: the email address, role, who added it, and when it was accepted, revoked, or expired.
- Student work: board cards, the strings that connect them, links, and uploaded pictures or files, plus the submission status (draft, turned in, or returned).
- Teacher content: boards, the learning goal and student instructions, and written feedback returned to students.
- For uploaded files: the original file name, file type, size, a checksum, and the malware-scan result.
- Security records: a hashed sign-in session token and its expiry, and an audit log of which account created, changed, submitted, returned, or deleted which board or file, and when. The audit log does not copy board or file content.
- Our hosting provider’s request logs, which include IP address, browser type, and the page requested. We do not copy these into the application database.
- Usage statistics: which parts of RedString for Schools are used and when, such as pages opened, boards created or turned in, and time spent in the app, linked to the account. They are recorded by our own application and kept in our own database. We use no third-party analytics, advertising, or tracking services.
- Teacher feedback: answers teachers choose to give to short, optional in-app questions about the product. Students are not surveyed.
What we never collect
RedString for Schools does not ask for or store names as a data field, passwords, dates of birth, addresses, phone numbers, grades or test scores, attendance, demographic, health, disability, IEP or 504, free- or reduced-lunch, or parent or guardian information. Students and teachers may choose to type information into a board; we do not request, index, or analyze it. The product does not use location tracking, RFID, cameras, microphones, or recording of any kind.
How we use Student Data
We use Student Data and Teacher Data only to provide RedString for Schools to the district that provided it. We do not sell, rent, or trade it. We do not use it for advertising or marketing, to build profiles, to train artificial-intelligence models, or to develop unrelated products. We use usage statistics and teacher feedback only to maintain and improve RedString for Schools. We do not publish Student Data on the Internet. Boards and submissions are shown only to signed-in members of the same district and class whose role requires them.
Where data is stored
- Application database (accounts, rosters, boards, submissions, audit records, usage statistics, and teacher feedback): Turso, hosted on Amazon Web Services in the United States (us-east-1, Virginia). Encrypted backups are kept in Amazon S3 in the United States.
- Uploaded pictures and files: Cloudflare R2 private object storage in North America (United States and Canada).
- Malware scanning: uploaded files are scanned in memory by a Cloudflare-hosted ClamAV service in the European Union before they are accepted. The scanner does not keep a copy of the file.
- Application hosting: Vercel, in the United States (Washington, D.C. region).
Student Data is never stored or processed outside the United States, Canada, and the European Union. We will provide this list to a district on request and will notify districts before changing a storage location.
Subprocessors
These are the only companies that process Student Data or Teacher Data on our behalf:
| Company | Purpose | Data |
|---|---|---|
| Turso (ChiselStrike, Inc.) | Application database | All records listed above |
| Cloudflare, Inc. | Private file storage and malware scanning | Uploaded pictures and files |
| Vercel, Inc. | Application hosting | All data in transit; request logs |
| Google LLC | Sign-in through the district’s own Google Workspace | Sign-in event, account identifier, and email |
Each subprocessor is bound by written data-protection terms at least as protective as our district agreements and receives only the data needed for its purpose. If a subprocessor fails to protect Student Data, we will notify the affected districts, remove its access, and make sure the data it holds is returned or securely deleted. We will update this list and notify districts before adding a subprocessor.
Security safeguards
- Encryption in transit: every connection uses HTTPS (TLS), including connections between our services.
- Encryption at rest: the database volumes, database backups, and file storage are encrypted, and each uploaded file is also stored with server-side AES-256 encryption.
- Sign-in: only Google Workspace accounts from district domains that we have approved can sign in. We never receive or store a password. Sessions expire after 12 hours, and we store only a hash of the session token.
- Access control: every request is checked on the server against the user’s district, class, and role. Each district’s data is kept separate, and users can reach only data in their own district.
- Files: pictures and files are checked for type and size (10 MB maximum), scanned for malware before acceptance, stored privately with no public link, and served only to authorized users.
- Audit logging: significant actions are recorded in an append-only audit log so they can be traced to an individual account.
- Administration: production systems are available only to authorized RedString personnel using accounts protected by multi-factor authentication. Credentials are kept out of source code and logs.
- Maintenance: we monitor security advisories and apply security updates to our software and dependencies promptly.
We manage our security program using the Center for Internet Security (CIS) Critical Security Controls, Implementation Group 1, as a baseline, scaled to the size of our organization.
Training and access
Anyone at RedString who could access Student Data is trained on FERPA, COPPA, and applicable state student-privacy laws before receiving access, and at least once a year after that. Access is limited to people who need it to provide or support the service, and we review it regularly. RedString personnel do not have direct contact with students; if that changes, they will pass a criminal background check first.
Incident response and breach notification
We keep a written incident response plan. If we suspect unauthorized access to Student Data, we will:
- Contain the incident and preserve evidence.
- Notify the affected district within 72 hours of confirming a breach, or sooner where a signed agreement or state law requires it (for example, within 24 hours for Virginia districts). Notice will include what happened, when, what data was involved, how many records were affected if known, what we are doing about it, and a contact person.
- Cooperate with the district, law enforcement, and state agencies, and follow the reimbursement and notification terms in the district’s signed agreement.
- Review the incident afterward and fix its cause.
A summary of the incident response plan is available to any district on request.
Retention, return, and deletion
We keep Student Data only as long as the district needs it. Unless a district’s agreement sets a different period, each district’s accounts, boards, submissions, files, rosters, audit records, usage statistics, and teacher feedback are deleted one year after the district’s classroom activity ends. When a district asks us to return or delete its data, or when our agreement ends, we will do so within 30 days (or the shorter period required by its agreement or state law) and confirm the deletion in writing. Database backups expire under our provider’s backup schedule after deletion. We do not keep copies of Student Data for any other purpose.
Parents, students, and district rights
The district owns and controls its Student Data. Parents, guardians, and eligible students who want to review, correct, or delete Student Data should contact their school district, and we will help the district respond. We follow each district’s Parents’ Bill of Rights for Data Privacy and Security where one applies. If we receive a request directly, we will refer it to the district.
Accessibility
We are committed to making RedString for Schools usable by every student and teacher, including people who use a keyboard, screen reader, magnification, or other assistive technology. Our target is the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, the standard used by the Department of Justice’s rule under Title II of the Americans with Disabilities Act and by Colorado’s accessibility rules.
- Current status: on October 6, 2026 we evaluated the product against WCAG 2.2 Level A and AA with automated testing, keyboard testing of every teacher and student board task, and testing with the Orca screen reader, and we fixed the issues we found. No third-party accessibility evaluation has been done yet.
- Known limitation: the investigation board is a visual, spatial canvas. Every board task works from a keyboard and with a screen reader, and a text outline lists every card and connection by title. Moving cards with the arrow keys requires the screen reader’s focus mode. Testing with NVDA, JAWS, and VoiceOver has not yet been done.
- How we evaluate: automated tests on every change, keyboard testing, and screen-reader testing, measured against WCAG 2.2 AA.
- Accessibility Conformance Report: our self-evaluated Accessibility Conformance Report, using the VPAT 2.5 template and dated October 6, 2026, is available to any district on request. We will update it after testing with additional screen readers and after any significant product change.
- Documentation and support: this page and our support are provided as accessible HTML and email. On request, we will provide a test account so a district can verify accessibility itself.
Accessibility remediation plan
Anyone may report an accessibility barrier to sjtechllc.team@gmail.com. We will:
- Acknowledge the report within 2 business days.
- Within 5 business days, work with the district on an interim accommodation so the affected student or teacher can complete the task.
- Fix a barrier that blocks sign-in or creating, editing, submitting, or reviewing a board within 30 days, and fix other WCAG 2.1 AA issues within 90 days. If a fix will take longer, we will tell the district why and give a date.
- Retest each fix, tell the person and district who reported it, and record it in the next Accessibility Conformance Report.
Changes to this plan
We review this plan at least once a year. We will notify districts with active agreements before any material change and publish each new version on this page with its effective date.
Contact
SJ Tech Solution LLC · Privacy and security questions: sjtechllc.team@gmail.com