Data Security

At Bradnova Technologies, security is not an afterthought — it is a core part of how we build and operate NovaEnglish. We apply industry-standard security practices across every layer of our infrastructure, from how we store your data to how our engineers access production systems.

We are committed to transparency. This document describes in plain language the specific technical and organisational measures we have in place to protect your personal data.

Data in transit

All communication between your browser or app and our servers is encrypted using TLS 1.2 or TLS 1.3 (Transport Layer Security). We enforce HTTPS for all connections and reject unencrypted HTTP requests. Our SSL certificates are managed automatically and renewed before expiry.

Data at rest

All database volumes, backups, and file storage are encrypted at rest using AES-256 (Advanced Encryption Standard with 256-bit keys). This is the same encryption standard used by banks and government agencies worldwide.

Password hashing

User passwords are never stored in plain text. When you create or change a password, it is hashed using bcrypt with a work factor of 12, which makes brute-force attacks computationally expensive. We cannot read your password — if you forget it, you must reset it.

Sensitive tokens

Authentication tokens (JWTs) are signed with strong secret keys and have short expiry periods (1 hour for access tokens, 7 days for refresh tokens). API keys and service credentials are never hardcoded in source code and are managed via environment variables in our deployment platform.

Hosting provider

NovaEnglish is hosted on Supabase (PostgreSQL database, authentication, file storage) and Vercel (web hosting and CDN). Both providers maintain comprehensive security certifications:

• Supabase: SOC 2 Type II, ISO 27001
• Vercel: SOC 2 Type II

Data location

User data is stored on servers located in the European Union (Ireland, eu-west-1). We do not transfer personal data outside the EEA except where covered by Standard Contractual Clauses (SCCs) with our sub-processors (e.g., Anthropic for AI processing).

Redundancy & backups

Our database infrastructure uses multi-region replication and automated daily backups with a 30-day retention period. In the event of infrastructure failure, our Recovery Time Objective (RTO) is under 4 hours and Recovery Point Objective (RPO) is under 1 hour.

Network security

Our infrastructure is protected by firewalls configured to allow only required network traffic. Database servers are not publicly accessible — they are only reachable from our application servers via private networking. We use DDoS protection at the CDN level.

Row-Level Security (RLS)

Our Supabase database enforces Row-Level Security (RLS) policies on all tables containing personal data. RLS is a PostgreSQL feature that ensures database queries automatically filter results to the records the authenticated user is permitted to see — regardless of what the application layer requests. Even in the event of an application bug, RLS prevents one user from accessing another user's data.

Service roles

Our application uses a principle of least privilege. The public-facing API uses an anon key with minimal permissions. Server-side operations that require broader database access use a service-role key that is never exposed to the client side.

Admin access

Production database access for Bradnova employees is restricted to senior engineers and requires authentication via hardware MFA key. All admin actions are logged and reviewed periodically.

User authentication is handled by Supabase Auth, which provides:

• Secure session management with HTTP-only cookies (preventing XSS access to tokens)
• Protection against common auth attacks (brute force, credential stuffing) via rate limiting
• Email verification for new accounts
• Secure password reset flows using time-limited, single-use tokens
• OAuth 2.0 support for Google sign-in

We recommend enabling a strong, unique password for your account. A future update will add optional two-factor authentication (TOTP) for all users.

We engage the following sub-processors who handle personal data on our behalf. Each is bound by a Data Processing Agreement (DPA) and is contractually required to maintain appropriate security standards:

A current, complete list of sub-processors is available on request via privacy@novaenglish.com.

We maintain comprehensive logging and monitoring to detect and respond to security incidents:

• Application logs: Server requests, errors, and performance metrics are logged and retained for 90 days
• Authentication logs: Login attempts (successful and failed), password changes, and session activity are logged and monitored for anomalies
• Database logs: Significant database operations are logged, particularly for admin access
• Uptime monitoring: Automated health checks every 60 seconds with immediate alerts on failure
• Anomaly detection: Rate limiting and automated blocking of IPs that exhibit suspicious behaviour

We have a documented incident response plan that covers detection, containment, eradication, recovery, and post-incident review. Key aspects:

• Detection: Automated alerts notify our engineering team immediately of suspected security incidents
• Assessment: We triage incidents within 2 hours of detection to determine scope and severity
• Notification: If a breach is confirmed that poses risk to users, we will notify affected users and the relevant data protection authority within 72 hours, as required by GDPR
• Remediation: We fix the root cause, patch affected systems, and implement additional controls to prevent recurrence
• Review: All security incidents are reviewed in a post-mortem meeting and the lessons learned are documented

We proactively manage security vulnerabilities through:

• Dependency scanning: Automated scans of our npm packages and dependencies to identify known vulnerabilities
• Code review: All code changes go through peer review before deployment, with security considerations as part of the checklist
• Penetration testing: We conduct annual third-party penetration tests of our web application and API
• OWASP compliance: Our development team follows OWASP Top 10 guidelines to prevent the most common web application vulnerabilities

Bradnova employees follow strict protocols when handling personal data:

• Access to production systems is granted on a need-to-know basis only
• All employees complete security awareness training during onboarding and annually
• Production database access requires MFA and is reviewed quarterly
• Employee access is revoked immediately upon departure from the company
• We maintain a record of who has access to what and review it regularly

We value the work of security researchers. If you discover a potential security vulnerability in NovaEnglish, please report it to us responsibly:

Please do not exploit vulnerabilities or access data that is not yours. We ask that you allow us reasonable time to remediate before any public disclosure.