Data Security Addendum

Version 1.0 / Last Updated: March 25, 2026

OVERVIEW

This Data Security Addendum (“Addendum”) provides detailed information about myOwl’s security architecture, data protection practices, and compliance measures. This document is intended for school IT directors, security teams, and other stakeholders evaluating myOwl for institutional adoption.

For complete privacy practices, please refer to our Privacy Policy (available at https://getmyowl.com/privacy-policy/).

1. EXECUTIVE SUMMARY

myOwl’s Commitment to Data Security:

  • ✅ Zero passwords stored — We use OAuth 2.0 for all LMS/calendar/athletic system authentication
  • ✅ AES-256 encryption — All student data encrypted at rest
  • ✅ TLS 1.2+ encryption — All data encrypted in transit
  • ✅ No third-party analytics — We do not use Google Analytics or other third-party analytics on student data
  • ✅ No data sharing — We do not sell, rent, or share student data with third parties
  • ✅ FERPA compliant — We are a service provider under FERPA; student records remain confidential
  • ✅ COPPA compliant — Full compliance with children’s online privacy requirements
  • ✅ SOC 2 Type II roadmap — Targeting certification within 12 months of achieving product-market fit

2. INFRASTRUCTURE & HOSTING

2.1 Cloud Infrastructure

Provider: Amazon Web Services (AWS)

Data Center Locations: US regions (us-east-1, us-west-2)

Compliance Certifications:

  • AWS is SOC 2 Type II certified
  • AWS is ISO 27001 certified
  • AWS complies with HIPAA, FedRAMP, and other standards

Redundancy & Availability:

  • Multi-AZ (Availability Zone) deployment for high availability
  • Automated backups with 30-day retention
  • Disaster recovery procedures in place

Physical Security:

  • AWS data centers maintain 24/7 security, surveillance, and access controls
  • Full audit trail of all physical access

See AWS Compliance documentation: https://aws.amazon.com/compliance/

3. DATA ENCRYPTION

3.1 Encryption at Rest

Standard: AES-256 encryption

Scope: All student data stored on myOwl servers, including:

  • Account information (name, email, student ID)
  • LMS sync data (assignments, grades, schedules)
  • Athletic schedule data
  • Study plans and progress tracking
  • Usage logs

Implementation:

  • Database-level encryption (AWS RDS encryption)
  • Application-level encryption for sensitive fields
  • Key management through AWS Key Management Service (KMS)

Key Rotation: Encryption keys are rotated annually and upon any suspected compromise.

3.2 Encryption in Transit

Standard: TLS 1.2 or higher (HTTPS)

Scope: All data transmitted between:

  • Student/parent devices and myOwl servers
  • myOwl servers and LMS/calendar/athletic system providers
  • myOwl infrastructure components

Certificate Management:

  • SSL/TLS certificates issued by trusted Certificate Authorities
  • Certificates renewed 30 days before expiration
  • HSTS (HTTP Strict Transport Security) enabled to prevent downgrade attacks

Cipher Suites: Only strong cipher suites are enabled; weak ciphers are disabled.

3.3 OAuth Token Security

Standard: OAuth 2.0 with encrypted token storage

Scope: Tokens received from Google, Canvas, Schoology, TeamSnap, and other LMS/calendar/athletic system providers

Storage:

  • All OAuth tokens encrypted at rest using AES-256
  • Tokens stored in isolated, access-restricted database
  • Tokens never logged or exposed in error messages

Transmission:

  • Tokens transmitted over TLS 1.2+ only
  • Tokens never stored in browser cookies or local storage
  • Tokens handled only server-side

Revocation:

  • Students can revoke token access at any time through myOwl settings or provider settings
  • Revoked tokens are immediately deleted from myOwl systems
  • Token expiration policies enforced per OAuth provider requirements

4. ACCESS CONTROLS

4.1 User Access

Student Access:

  • Students can only view their own data
  • Role-based access control (RBAC) enforced
  • Session timeout after 30 minutes of inactivity

Parent/Guardian Access:

  • Parents can view only their child’s data
  • Parents cannot view data of other students
  • Role-based access control enforced

School Administrator Access (if applicable):

  • Schools can view aggregate usage data for their institution
  • Schools cannot view individual student data, grades, or study plans
  • Access limited to designated school administrators
4.2 Employee Access

Principle of Least Privilege:

  • Employees have access only to data necessary for their role
  • Access is logged and monitored
  • Regular access audits conducted quarterly

Access Categories:

  • Engineering/Operations: Can access production systems for maintenance and debugging (with audit logging)
  • Support: Can access customer support tickets and basic account information (no sensitive data)
  • Executives: Limited to anonymized, aggregate reporting
  • Other employees: No access to student data

Authentication:

  • All employee access requires multi-factor authentication (MFA)
  • Strong password requirements enforced
  • VPN required for remote access

Termination Protocol:

  • All access revoked immediately upon employee termination
  • API keys and credentials rotated
  • Access logs reviewed for any unauthorized activity
4.3 Third-Party Vendor Access

Service Providers:

  • Vendors have access only to data necessary for their specific function
  • Access is contractually restricted and monitored
  • All vendors sign Data Processing Agreements (DPAs) and Business Associate Agreements (BAAs) where applicable

Current Vendors:

  • AWS: Infrastructure hosting (access to encrypted data storage)
  • smtp.com: Email delivery (access to student email addresses for notifications only)

No other third parties have access to student data.

5. AUTHENTICATION & PASSWORD MANAGEMENT

5.1 Password Security

myOwl Account Passwords:

  • Passwords hashed using bcrypt (with salt) or Argon2
  • Minimum 8 characters required
  • Complexity requirements enforced (uppercase, lowercase, numbers, symbols)
  • Password reset available via email verification

LMS/Calendar/Athletic System Passwords:

  • We do NOT store these passwords
  • Authentication handled via OAuth 2.0 directly with the provider
  • Students log in directly to their LMS/calendar/athletic system provider
  • myOwl receives only a secure token, never the password
5.2 Multi-Factor Authentication (MFA)

Current Status:

  • MFA is required for all myOwl employee access
  • MFA is optional for student/parent accounts (recommended)

Future Roadmap:

  • MFA will be offered as a user-selectable option for all accounts
  • SMS, authenticator app, and email-based MFA options planned
5.3 Session Management

Session Timeout:

  • Web sessions expire after 30 minutes of inactivity
  • Mobile app sessions expire after 1 hour of inactivity
  • Users are prompted before session expires

Session Security:

  • Session tokens are cryptographically secure and unpredictable
  • Sessions stored server-side only (not in cookies)
  • CSRF (Cross-Site Request Forgery) protection enabled

6. SECURITY AUDITS & TESTING

6.1 Internal Security Reviews

Frequency: Quarterly

Scope:

  • Code review for security vulnerabilities
  • Database access logs review
  • Network security configuration review
  • Compliance checklist verification

Responsibility: Chief Technology Officer (CTO) and security-focused engineering team

6.2 Penetration Testing

Frequency: Annually (planned)

Scope:

  • External penetration testing by third-party security firm
  • Testing of web application, API, and infrastructure
  • Vulnerability assessment and remediation

Timeline: First penetration test scheduled for Q3 2025

6.3 Vulnerability Management

Vulnerability Disclosure:

  • myOwl maintains a responsible disclosure policy
  • Security researchers can report vulnerabilities to [email protected]
  • Reported vulnerabilities are reviewed within 24 hours
  • Critical vulnerabilities are patched within 48 hours
  • All researchers are thanked and credited (with permission)

Patch Management:

  • Security patches are applied within 48 hours of release
  • Critical infrastructure updates are tested in staging before production deployment
  • All patches are logged and tracked
6.4 Dependency Management

Software Dependencies:

  • All third-party libraries and dependencies are tracked
  • Regular updates applied to address security vulnerabilities
  • Automated dependency scanning tools used to identify vulnerable packages

Container Security (if applicable):

  • Docker images scanned for vulnerabilities before deployment
  • Base images kept up-to-date with latest security patches

7. INCIDENT RESPONSE & BREACH NOTIFICATION

7.1 Incident Response Plan

Incident Response Team:

  • Chief Technology Officer (CTO)
  • Security-focused engineer
  • Legal/compliance officer

Response Timeline:

Incident Severity Detection Investigation Notification Resolution
Critical (data breach, unauthorized access) Immediate Within 2 hours Within 24 hours Within 48 hours
High (security vulnerability, failed authentication) Within 1 hour Within 4 hours Within 48 hours Within 1 week
Medium (suspicious activity, failed access attempt) Within 4 hours Within 24 hours Within 1 week Within 2 weeks
Low (non-security issue, minor bug) Within 24 hours Within 1 week As needed Within 1 month

 

7.2 Data Breach Notification

If a data breach occurs:

  1. Immediate Actions (within 2 hours):
    • Isolate affected systems
    • Preserve evidence and logs
    • Notify incident response team
  2. Investigation (within 24 hours):
    • Determine scope of breach (what data, how many users)
    • Identify root cause
    • Assess ongoing risk
  3. Notification (within 30 days):
    • Notify affected students and parents via email
    • Notify affected schools/districts
    • Provide clear description of:
      • What data was accessed
      • When the breach occurred
      • What steps we’re taking to prevent future breaches
      • What users should do (e.g., monitor accounts, change passwords)
      • Contact information for questions
  4. Cooperation with Authorities:
    • Cooperate with law enforcement if required
    • Comply with state breach notification laws
    • Provide forensic reports as requested
    • Patch vulnerability that caused breach
    • Implement additional security measures
    • Provide credit monitoring if applicable
    • Conduct post-incident review
  5. Remediation:
    • Patch vulnerability that caused breach
    • Implement additional security measures
    • Provide credit monitoring if applicable
    • Conduct post-incident review

Breach Notification Contact: [email protected]

8. COMPLIANCE CERTIFICATIONS & STANDARDS

8.1 Current Compliance
Standard Status Notes
FERPA (Family Educational Rights and Privacy Act) ✅ Compliant myOwl is a service provider; student records are confidential
COPPA (Children’s Online Privacy Protection Act) ✅ Compliant Verifiable parental consent required for children under 13
SOPIPA (California Student Online Personal Information Protection Act) ✅ Compliant No sale of student data; transparency in data practices
New York Education Law 2-d ✅ Compliant Student data privacy requirements for vendors
VMPPA (Virginia Marketplace of Provider Privacy Act) ✅ Compliant Provider transparency and data security requirements
Colorado CPA (Colorado Privacy Act) ✅ Compliant Student data protection and deletion rights
HIPAA ⚠️ Not applicable myOwl does not collect health information
GDPR ⚠️ Not applicable myOwl serves US-based students; GDPR not required

 

8.2 SOC 2 Type II Roadmap

Current Status: Not yet certified

Target Timeline: Certification within 12 months of achieving product-market fit and securing initial school pilots

Roadmap:

  • Q2 2025: Engage SOC 2 audit firm
  • Q3–Q4 2025: Implement SOC 2 control framework
  • Q1–Q2 2026: Conduct SOC 2 audit
  • Q2–Q3 2026: Remediate audit findings
  • Q3–Q4 2026: Receive SOC 2 Type II certification

In the Interim:

  • myOwl maintains industry-standard security practices (see Sections 3–7)
  • Schools can request our current security documentation and audit progress
  • Contact: [email protected]

9. DATA RETENTION & DELETION

9.1 Retention Policy
Data Type Retention Period Deletion Method
Account Information Until account deletion Cryptographic erasure
LMS/Calendar/Athletic Data Until account deletion Cryptographic erasure
Usage Logs 12 months Automated deletion
Study Plans & Progress Until account deletion Cryptographic erasure
Support Tickets 2 years Manual deletion
Backups 30 days after account deletion Automated purge
Anonymized Analytics Indefinite N/A (cannot be linked to individuals)

 

9.2 Deletion Process

User-Initiated Deletion:

  1. User requests deletion through account settings or email ([email protected])
  2. Account marked for deletion immediately
  3. Data removed from active systems within 24 hours
  4. Backups purged within 30 days
  5. Confirmation email sent to user

School-Initiated Deletion (if applicable):

  1. School requests deletion of all student data
  2. Data removed from active systems within 24 hours
  3. Backups purged within 30 days
  4. Confirmation provided to school

Cryptographic Erasure:

  • Encrypted data is deleted by destroying encryption keys
  • Data becomes unrecoverable without the key
  • More efficient than overwriting for large datasets

10. VENDOR MANAGEMENT

10.1 Third-Party Vendors

Amazon Web Services (AWS)

  • Purpose: Cloud infrastructure and data storage
  • Data Access: All encrypted student data
  • Agreement: AWS Service Level Agreement (SLA) and Data Processing Agreement (DPA)
  • Compliance: SOC 2 Type II, ISO 27001, HIPAA
  • Contact: See AWS Compliance Portal

smtp.com

  • Purpose: Email delivery for notifications
  • Data Access: Student email addresses only (no other student data)
  • Agreement: Data Processing Agreement (DPA)
  • Compliance: GDPR, SOC 2 Type II
  • Contact: See smtp.com Privacy Policy
10.2 Vendor Evaluation

Criteria for Selecting Vendors:

  • Security certifications (SOC 2, ISO 27001, etc.)
  • Data protection practices
  • Incident response procedures
  • Financial stability and reputation
  • Compliance with FERPA and state laws

Ongoing Monitoring:

  • Annual review of vendor security practices
  • Quarterly review of vendor access logs
  • Immediate notification if vendor experiences security incident
10.3 Data Processing Agreements (DPAs)

All vendors that process student data are required to sign a Data Processing Agreement that includes:

  • Purpose and scope of data processing
  • Data security obligations
  • Incident notification requirements
  • Data deletion procedures
  • Audit and compliance provisions
  • Prohibition on unauthorized data sharing

11. NETWORK SECURITY

11.1 Firewall & Network Architecture

Firewall Configuration:

  • AWS Security Groups restrict inbound/outbound traffic
  • Only necessary ports open (HTTPS 443, etc.)
  • Outbound traffic restricted to known services only

Network Segmentation:

  • Student data isolated in restricted VPC (Virtual Private Cloud)
  • Database servers not directly accessible from internet
  • Application servers behind load balancer and Web Application Firewall (WAF)
11.2 Web Application Firewall (WAF)

Purpose: Protect against common web attacks (SQL injection, XSS, DDoS, etc.)

Features:

  • Rate limiting to prevent brute force attacks
  • IP reputation blocking
  • Geo-blocking (if applicable)
  • Custom rules for known attack patterns
11.3 DDoS Protection

Provider: AWS Shield Standard (included with AWS)

Features:

  • Automatic DDoS attack detection and mitigation
  • Protection against Layer 3 and 4 attacks
  • 24/7 monitoring and response

Future: AWS Shield Advanced planned for additional Layer 7 protection

Mailing Address: [Your Address]
Response Time: We will respond to all privacy inquiries within 10 business days

12. API SECURITY

12.1 API Authentication

Method: OAuth 2.0 tokens with JWT (JSON Web Tokens)

Token Security:

  • Tokens are short-lived (15 minutes to 1 hour)
  • Refresh tokens used to obtain new access tokens
  • Tokens signed with HMAC-SHA256 or RSA
  • Token revocation supported
12.2 API Rate Limiting

Purpose: Prevent abuse and brute force attacks

Limits:

  • 100 requests per minute per user
  • 1,000 requests per minute per API key
  • Burst limits enforced
12.3 API Logging & Monitoring

Logged Data:

  • All API requests logged with timestamp, user, endpoint, and response code
  • Error messages logged for debugging
  • Sensitive data (passwords, tokens) never logged

Log Retention: 12 months

Log Security: Logs encrypted at rest and in transit

13. COMPLIANCE WITH SCHOOL POLICIES

13.1 School Network Integration

myOwl works within school security frameworks:

  • ✅ Uses OAuth 2.0 (no passwords required)
  • ✅ Complies with FERPA
  • ✅ Complies with state student data privacy laws
  • ✅ Does not exfiltrate contact lists or payment data
  • ✅ Can be blocked at school firewall if desired
  • ✅ Provides Data Processing Agreement for schools
13.2 School IT Audit Support

myOwl provides the following to school IT for audit purposes:

  • Current security documentation
  • Encryption specifications
  • Vendor list and compliance certifications
  • Incident response plan
  • Data retention and deletion procedures
  • SOC 2 audit progress and timeline
  • References from other schools using myOwl

Contact: [email protected]

14. RESPONSIBLE DISCLOSURE & SECURITY CONTACT

14.1 Security Vulnerability Reporting

If you discover a security vulnerability in myOwl, please report it responsibly:

Email: [email protected]

 

Subject: [SECURITY] [Vulnerability Type] — [Brief Description]

Please include:

  • Description of the vulnerability
  • Steps to reproduce
  • Potential impact
  • Your contact information (optional)

We will:

  • Acknowledge your report within 24 hours
  • Investigate and assess severity
  • Provide updates on remediation
  • Credit you in our security advisory (with permission)

Please do NOT:

  • Publicly disclose the vulnerability before we’ve had time to patch
  • Access data beyond what’s necessary to demonstrate the vulnerability
  • Disrupt service or access accounts without authorization

15. SECURITY ROADMAP & FUTURE IMPROVEMENTS

15.1 Near-Term (Next 6 Months)
  •  Implement optional multi-factor authentication (MFA) for user accounts
  •  Conduct first annual penetration test (Q3 2025)
  •  Publish security incident response plan publicly
  •  Implement automated security scanning in CI/CD pipeline
15.2 Medium-Term (6–12 Months)
  •  Achieve SOC 2 Type II certification
  •  Implement advanced threat detection and monitoring
  •  Expand incident response team training
  •  Conduct security awareness training for all employees
15.3 Long-Term (12+ Months)
  •  Evaluate ISO 27001 certification
  •  Implement zero-trust security architecture
  •  Establish bug bounty program
  •  Expand third-party security audits

16. DOCUMENT CONTROL & UPDATES

Version: 1.0
Last Updated: March 25, 2026
Next Review: March 25, 2026

Change Log:

Version Date Changes
1.0 March 25, 2026 Initial release

This document will be updated annually or as significant security changes occur. Material updates will be communicated to schools via email.

17. CONTACTS & QUESTIONS

For questions about myOwl’s security practices:

Email: [email protected]

Response Time: Within 2 business days

For Privacy Questions:

Email: [email protected]
Response Time: Within 10 business days