Security

EasyLessonPlan is a small service run by one teacher. This page describes the protections that are actually built into it, in plain terms. It deliberately avoids the language you often see on security pages — certifications we do not hold, guarantees no service can honestly make, and promises about other companies' systems that we have not seen in writing. Where something depends on a provider rather than on our own code, we say so instead of claiming it.

The companies that process information on our behalf are listed on the Service Providers and Subprocessors page.

Every connection the application makes — to the database, to the sign-in service, and to the AI provider — is made over HTTPS, so information is encrypted while it travels between your browser, our servers and those providers.

A lesson file you upload to the Lesson Differentiator is never stored. Its text is read in memory, used for the adaptation, and the file is discarded; if you save the result, only the file's name is kept alongside it, not the file.

How information is stored on disk is handled by our database provider under its own arrangements. We have not published a description of that here because we would be describing someone else's infrastructure rather than something we operate.

Accounts are held in a managed authentication service. You can sign in with an email address and password, or with Google. We never see or store your Google password, and passwords for email accounts are handled by the authentication provider — they are not stored in our own tables.

• A new password must be at least eight characters when you create an account.
• A forgotten password is reset through a link sent to your email address, so resetting a password requires access to that inbox.
• Every request to the server carries a signed session token, and the server checks that token before it will do anything with your account. A request with no token, or a malformed one, is refused rather than treated as anonymous.
• Sign-up rejects known throwaway and temporary inbox providers, and the same check runs again on the server so that bypassing the form does not help.

Choose a password you do not use anywhere else, and keep the inbox attached to your account secure — anyone who can read that inbox can reset your password.

Your lesson plans, adaptations, assessments, unit plans and schemes of work are private to your account. That separation is enforced in the database itself, not only in the application: every table carrying account data has row-level security switched on, and the rules attached to those tables compare the signed-in user's ID against the row's owner. A query that asks for another teacher's row returns nothing, even if the application were asked to run it.

The only rows deliberately readable by everyone are public website content — published blog posts, their categories, tags and images. No table of teacher-created content is readable that way.

There is also a limit on how fast generations can be requested from one account, which runs on the server and counts every model call, so one account cannot be driven to make continuous automated requests.

There is one administrator role. It is held in its own table and checked by the database rather than being a flag on a profile that could be edited, and it is granted to the operator's account only.

That administrator role does not give access to teachers' lesson content or profiles. No database rule grants the administrator a view of lesson plans, adaptations, assessments, planning resources or behaviour support plans. What it does allow is managing the blog, school licences and seats, and reading school invoice requests.

Being honest about the limit of that statement: as the operator of the service, we hold the database credentials that the billing and webhook code needs, and those credentials are not bound by the rules described above. We do not browse teachers' lesson content, and nothing in the product exposes it to us, but you should understand that technical access exists at the infrastructure level, as it does for any hosted service. If you email us for support, we only see what you choose to send us.

When you generate something, the details you enter — and the text of any lesson you upload or paste — are sent to our AI provider so the content can be produced. Requests go through the Lovable AI Gateway to the model openai/gpt-6-astra.

We do not use your inputs or generated outputs to train any model. We cannot make the same statement on the gateway operator's or model provider's behalf: we do not hold written terms from them about whether prompts and outputs are retained, for how long, or whether they are used for their own training. Rather than repeat a reassurance we cannot evidence, we are telling you plainly that we do not have it. Treat anything you enter as content that leaves our systems, and email us at easylessons@easylessons.app if you need the current position before you use the service.

Describe the need, not the child. "A Primary 5 learner who reads two years below grade level and loses focus after ten minutes" gives the tools everything they need.

Please do not enter:

• Student names, initials, admission numbers or other identifiers.
• Diagnoses, medical or psychological reports, or therapy notes.
• Safeguarding records, behaviour incident logs naming a child, or family details.
• Anything else your school holds as a confidential student record.

The service does not detect, mask or remove this kind of information if you enter it. There is no filter that recognises a student's name. Whatever you type is sent to the AI provider as written and saved with your plan, so leaving it out is the only protection.

The Classroom Behaviour and Engagement Planner does have one safeguarding check: certain high-risk topics — disclosures of harm, abuse, self-harm or suicide — stop the request before any model call is made and point you to your school's safeguarding and emergency procedures instead, because a classroom strategy is the wrong answer to a disclosure. It works by recognising particular words and phrases, so it will not catch every way of describing a serious concern, and it can occasionally stop an innocent sentence. It is a backstop, not a substitute for your school's procedures.

We do not run a backup system of our own. Database backup and restoration are part of the hosting arrangements provided by our database platform, and we have not set out their terms here because we would be describing a provider's process rather than one we operate and have verified.

What this means for you in practice: export anything you would be upset to lose. Every tool offers Word and PDF export, those exports are free, and a copy saved to your own computer or school drive does not depend on us.

Everything these tools produce is generated by an AI model, and AI-generated material can be wrong, biased, out of date, or unsuitable for your class. It can invent references, cite standards codes that do not exist or do not match your curriculum, misjudge what a particular age group can do, and suggest activities that are impractical or unsafe in a real classroom.

You are the professional in the room. Before teaching from anything generated here, check:

• Factual accuracy — content, dates, definitions, worked examples and answer keys.
• Curriculum fit — that standards, codes and objectives match the syllabus you actually teach, and that the level suits your learners.
• Differentiation suggestions — that adaptations for additional needs are appropriate for the learners in front of you, and consistent with any plan or professional advice already in place. These are suggestions to weigh, not recommendations from a specialist.
• Practical activity safety — equipment, materials, supervision ratios, allergies and your school's risk-assessment rules, especially for science, cooking, sport and anything involving heat, tools or chemicals.
• Biblical and religious references, where you use them — that quotations, references and interpretations are accurate and match your school's tradition and teaching.

Files exported from EasyLessonPlan carry a visible note and machine-readable metadata marking them as AI-generated and requiring teacher review. We do not record whether a review took place, so nothing we produce claims that one has.

If you find a security problem in EasyLessonPlan, or you think someone has gained access to your account, email easylessons@easylessons.app with "Security" in the subject line. Include enough detail to reproduce the issue. If you think your account is affected, change your password first and say so in the email.

The service is run by one person, so we are not going to promise a response time we might not meet. Reports are read and taken seriously, and we will tell you what we have done. Please give us a reasonable opportunity to fix a problem before you publish it, and please do not access, change or download other people's data while investigating — testing against your own account is fine.

If a security incident affects personal data, we will notify supervisory authorities and the people affected as required by applicable law and by our contractual obligations. The Privacy Policy sets out how personal data is handled and the rights you have over it.

We hold no security certification, and we are not going to imply one. You will not find "SOC 2 certified", "FERPA certified", "fully GDPR compliant", "end-to-end encrypted" or "100% secure" anywhere on this site, because none of those would be true. No online service can promise it cannot be breached. What we can do is describe the specific measures above, keep this page accurate as things change, and tell you plainly where a protection depends on a provider rather than on us.

• Privacy Policy — what we collect, why, and your rights over it.
• Terms & Conditions — the agreement covering your use of the service.
• Service Providers and Subprocessors — the companies that process information on our behalf.