Data Security and Privacy Plan

Building 21 protects the student, teacher, and principal data that schools entrust to us through a written data security and privacy program aligned to the NIST Cybersecurity Framework (CSF) v1.1. This plan describes that program for the schools, districts, and other educational agencies (EAs) we serve.

Services covered. Beacon LMS, Beacon Portfolio, Student Log, and the data warehouse and analytics dashboards that support school reporting (together, the "Education Services").

Our Education Services Privacy Policy describes what data we collect and how we use it. Where this plan and an EA's signed Data Privacy Agreement (DPA) differ, the DPA controls.

We meet each EA's data security and privacy requirements through written policies in six domains, applied to every system that holds student data, and reviewed at least once a year.

Policy domains. People Controls, Access Control, Data Protection, Data Disposition, Subprocessor Management, and Incident Response. Each policy states the rule, names an owner, and defines the evidence that shows the control is operating.

Over the life of a contract, we:

• Use student data only to provide the services in the EA's agreement.
• Keep a current register of every subprocessor, its data location, and the agreement that binds it.
• Review each policy at least annually, and whenever our systems, team, or obligations change materially.

Student data is encrypted at rest and in transit, hosted in the United States, and reachable only by users and staff whose role requires it.

Technical safeguards

• Encryption at rest. Production databases, file storage, and backups are encrypted using AES-based encryption managed by our hosting providers (Amazon Web Services and DigitalOcean).
• Encryption in transit. All connections to systems holding student data use HTTPS/TLS. Unencrypted connections are not permitted.
• Tenant isolation. Each user's access is bound to their school. The application filters every request so that a school's users can see only that school's data.
• Authentication. Users sign in with Google or with a username and password. Passwords are stored only as one-way hashes. Sessions use short-lived tokens that are revoked at logout.
• Network restriction. Production databases sit in private networks with no public access. Staff reach them only through a VPN or an IP allow-list. Public traffic passes through a web application firewall and DDoS protection.
• Secrets management. Application credentials are held in a managed secrets service or an access-controlled password vault, not in code.
• Monitoring and logging. Application errors and anomalies are monitored continuously. Data-change audit logging is in place for Beacon LMS and is being extended to the data warehouse.
• Backups. Automated, encrypted backups support point-in-time recovery.
• Non-production data. Test and staging environments use anonymized data, not live student data.

Administrative and operational safeguards

• Least privilege. Staff and service accounts receive only the access their role requires. Access is reviewed at least annually.
• Individual accountability. Credentials are individual or role-based and stored in an access-controlled vault.
• Gated high-impact actions. Irreversible actions, such as deleting a school's data, require a separate permission and explicit confirmation.
• Data minimization. We collect only what the services need. Demographic and special-indicator data enter only the data warehouse, and only when a school chooses to provide them.
• US data residency. Student data in our application, database, analytics, and monitoring systems is stored in the United States: Amazon Web Services (Oregon), DigitalOcean (New York), Google Looker (Virginia), and Sentry (US region). Files and reports kept in Google Workspace are covered by Google's data processing terms; we are setting a United States data-region policy for them.

Everyone with access to student data completes training on federal and state student privacy law before receiving access, and again every year. We are rolling this requirement out to current staff now.

What it covers.

• What counts as student data and personally identifiable information (PII)
• FERPA and the obligations of a "school official"
• Applicable state student privacy laws
• Building 21 security practices, including credential hygiene and phishing awareness
• How and when to report a suspected incident

How. Staff complete the U.S. Department of Education's Student Privacy Policy Office training plus a Building 21 briefing on our own practices. Completion is recorded per person, with the date, and renewed annually.

Every subprocessor with access to student data is bound by a written agreement today. Employees and contractors are being brought under signed agreements now, and new staff sign before receiving access.

Employees and contractors. Each person signs a confidentiality and data-handling agreement before receiving access. It requires:

• Use of student data only for authorized purposes
• No re-disclosure, and no personal or commercial use
• Compliance with Building 21 security practices
• Immediate reporting of suspected incidents
• Return or destruction of student data when the engagement ends

Obligations survive the end of employment or engagement. Access is granted only after the agreement is signed and training is complete, and is revoked the same day a person leaves. Status: the agreement is written; signatures from current staff are in progress.

Subprocessors. Before a vendor can access student data, we confirm a written data protection agreement is in place, confirm where it stores data, and add it to our subprocessor register. Current subprocessors:

If a subprocessor fails to meet its obligations, we notify the affected EA, remove its access, and ensure the data it held is returned or destroyed.

We notify the affected EA within 72 hours of confirming that student data was accessed without authorization, or sooner where the EA's agreement or state law requires it.

Detection. Incidents are identified through continuous application monitoring, infrastructure alerts, database audit logs, reports from staff (who are required to report suspected incidents immediately), and reports from schools and subprocessors.

Roles. An Incident Coordinator moves each incident through detection, containment, notification, and closure. A designated Notification Authority decides on and makes notifications to EAs.

Response process.

1. Open and log. Each incident is recorded in a shared incident log the moment it is reported, with timestamped findings, actions, and decisions.
2. Classify severity. Critical, major, or minor, which sets the pace of response.
3. Classify student data risk. Confirmed access, potential exposure under investigation, or contained (no system with student data affected).
4. Contain. Limit the impact first. A compromised environment's credentials are treated as exposed and rotated.
5. Investigate. Determine root cause and full scope, keeping confirmed findings separate from working assumptions.
6. Notify. Confirmed access triggers notification to the EA. If an investigation ends without ruling exposure in or out, we decide on notification rather than defaulting to silence.
7. Recover and review. Restore affected systems, then feed lessons learned back into our policies and system documentation.

What a notification includes, as known at the time and updated as we learn more:

• The types of personal information involved
• The date or date range of the incident, and the date of the notice
• A general description of what happened
• The number of records affected, if known
• What we have investigated and done so far
• Whether notice was delayed at law enforcement's request
• A point of contact at Building 21

We cooperate with the EA, state agencies, and law enforcement in any investigation. Where a breach is attributable to Building 21 or its subprocessors, we cover notification costs as the EA's agreement provides.

At the end of a contract, or on written request, we return the EA's data in a readable, standard format before disposing of it.

• Format. Exports are provided as CSV files, or another format agreed with the EA. Student-generated files are returned in their original formats.
• Delivery. Exports are delivered through a secure, access-controlled shared location designated with the EA, or another secure method the EA specifies.
• Timing. Within the window set by the EA's agreement, or within 60 days of a written request when the agreement sets none.
• Student accounts. Where the EA requests it, we help transfer student-generated content to a separate account controlled by the student.
• After transfer. Once the EA confirms receipt, or the agreed window closes, we dispose of the data as described in Section 7.

We destroy an EA's data by hard deletion in every system that holds it, and confirm the destruction to the EA in writing.

Timing. Within 60 days of a written request, or as the EA's agreement requires. Without a request, by the end of July following the end of the service agreement.

Method.

• Hard deletion. A school's records, files, and media are permanently deleted, not hidden or soft-deleted. In Beacon LMS, deletion runs through a separately permissioned process that shows the scope of the action and requires explicit confirmation.
• Every system. A disposition is complete only when data is removed from every system that holds it, including Beacon LMS, its file storage, and the data warehouse.
• Backups. Automated encrypted backups containing deleted data expire on their own fixed retention cycle, within 35 days. Any manually retained snapshot is reviewed and purged against completed dispositions; we are formalizing that review now. If a system is ever restored from backup during that window, we re-apply the deletion before the system returns to use.
• Physical media. Our hosting providers sanitize retired storage media under their own audited processes, consistent with NIST SP 800-88.
• De-identified data. Data that has been de-identified under the EA's agreement is not subject to disposal.

Certification. Every disposition is logged with the date, the operator, the school, and the method. We give the EA written confirmation stating the date and method of destruction, and sign the verification section of the EA's Directive for Disposition of Data (DPA Exhibit D) when one is used.

We follow each EA's data security and privacy policy, including any Parents' Bill of Rights for Data Privacy and Security the EA provides, which we treat as part of this plan for that EA.

• Where they differ. If an EA's policy is stricter than this plan, we follow the EA's policy for that EA's data.
• Parents and students. Requests from parents or eligible students to review, correct, or delete records are referred to the EA, and we support the EA's response.
• Changes. We give the EA notice before making material changes to our privacy practices, as its agreement requires.

Our program addresses all 23 NIST CSF v1.1 categories. Most are in place; the categories where we are still building controls say so.

Data security and privacy contact: Tom Gaffey, Senior Vice President of Technology & Innovation, tom@b-21.org

General inquiries: info@b-21.org

Mailing address: Building 21, 600 West Germantown Pike, Ste 400-144, Plymouth Meeting, PA 19462

This plan is reviewed at least once a year and updated as controls are completed.

Last updated: October 28, 2026