Skip to content
Bot Cadets

Security Program Summary

Last updated: October 13, 2026

The short version

  • We keep a written information security program to protect your child's information, as the FTC's COPPA Rule requires.
  • We collect very little, which is our first safeguard.
  • Data is encrypted in transit and at rest. Only the people who run Bot Cadets and our service providers can reach it, and our admin accounts require multi-factor authentication.
  • We check our risks and safeguards at least once a year, and we have a plan for handling incidents.

This page summarizes Bot Cadets' written information security program under the COPPA Rule (16 CFR 312.8). The full program is an internal document. It is sized for a small, early-stage service and will grow as Bot Cadets grows.

1. Who is responsible

Program coordinator: [RESPONSIBLE PERSON], Founder, mrcarterpark@gmail.com

The coordinator runs the program, keeps it written down and current, and is the contact for security questions and reports.

2. Collecting less

The best protection is not having the data at all. Bot Cadets:

  • collects no real names, emails, photos, voice, or location from children,
  • has no chat, no public posting, and no live AI,
  • uses no advertising, analytics, or tracking tools, and
  • deletes data on the schedule in our Data Retention Policy.

3. Risk assessment

At least once a year, and before any major change, the coordinator reviews:

  • what children's and parents' information we hold, and where,
  • what could go wrong, from the inside (mistakes, too much access) and the outside (account takeover, attacks, provider incidents), and
  • whether our current safeguards are enough for that risk.

The results are written down, with fixes and dates. Our safeguards are sized to how sensitive children's information is and to Bot Cadets' size.

4. Safeguards

Access control

  • Only [RESPONSIBLE PERSON] and people who need it to run Bot Cadets can access production systems.
  • Every admin account (hosting, database, email, code repository, domain) uses multi-factor authentication.
  • Access is removed promptly when someone no longer needs it.
  • Database row-level security rules let each parent read and change only their own family's data.
  • Secret keys are stored in our hosting provider's encrypted environment settings, never in code. Keys with full database access are used only on the server.

Encryption

  • All traffic uses HTTPS (TLS).
  • Our database and hosting providers encrypt stored data at rest.
  • Passwords are stored by our authentication provider in hashed form.

Building and running the service

  • Real children's data is never used for development or testing.
  • Children's information and final-project text are kept out of application logs and error reports.
  • Software dependencies are kept up to date, and security updates are applied promptly.
  • Code changes that touch children's data, sign-in, or database rules are checked against this program before release.
  • Database backups are automatic and kept only for a short, set period.

Service providers

  • We use a small number of established providers: Vercel (hosting), Supabase (login and database), and Resend (email).
  • Before a provider stores or handles children's information, we take reasonable steps to confirm it can keep that information confidential and secure, and we get its written assurance (through its data processing terms) that it will use reasonable measures to protect it.
  • We review this list at least once a year.

5. Testing and monitoring

  • We regularly test that one family cannot see another family's data.
  • We watch provider security alerts and review sign-in and error logs for unusual activity.
  • We test deletion and data export to make sure they work as described.

6. Incident response

If we suspect a security incident, we will:

  1. Contain it: stop the problem, for example by rotating keys, locking accounts, or taking a feature offline.
  2. Investigate: work out what happened, what information was involved, and whose.
  3. Notify: tell affected parents without unreasonable delay, and notify regulators where the law requires, including under California's breach notification law.
  4. Fix and learn: correct the cause, update this program, and record what we changed.

To report a security concern, email mrcarterpark@gmail.com. We welcome good-faith reports and will not take action against people who report issues responsibly.

7. Yearly review

At least once a year, the coordinator evaluates and updates the program based on the risk assessment, testing results, changes to Bot Cadets, new tools, and anything else that could affect security.

Last reviewed: October 13, 2026 Next review due: October 2027