Security questionnaires almost always ask how a vendor handles patching: how quickly known vulnerabilities are fixed, and how updates reach production without breaking things. This article answers that.
Summary
edyoucated is cloud software only. There is nothing for you to install, and therefore nothing for you to patch.
Every customer is always on the current version of the platform.
We scan continuously for vulnerabilities in our own code and in the third-party components we use.
Findings are assessed on whether they are actually exploitable in our setup, not just on a generic severity score, and are fixed on defined deadlines.
Every update, including a security fix, passes the same automated test gates and staged environments before it reaches you.
There is nothing for you to patch
edyoucated is delivered exclusively as multi-tenant cloud software. There is no on-premise version and no client software that runs in your own estate. This removes an entire category of risk: there is no version of edyoucated running anywhere that has fallen behind a security release, and no patch cycle you have to plan for.
Who is responsible for what
Layer | Responsible |
Physical infrastructure, network, host operating systems, managed runtimes | Our cloud providers. Both environments are ISO/IEC 27001 certified and are regularly penetration tested by certified independent partners. |
Application code and third-party components | edyoucated |
Platform configuration, access control, separation between customers | edyoucated |
Employee devices used to build and operate the platform | edyoucated |
Your own user administration: roles, identity provider configuration, offboarding your people | You |
How we find security issues
Continuous automated scanning of every third-party component our applications depend on, evaluated on a fixed weekly cycle.
Security advisory matching, which alerts us when a component we actually use is named in a newly published advisory.
Security bulletins from our cloud providers. Maintaining an information channel with our vendors about released updates and patches is a commitment in our technical and organisational measures.
Automated secret scanning across our code, which catches credentials that should never have been committed.
Continuous error and anomaly monitoring in production, reviewed on a weekly cadence, which surfaces unusual behaviour and attempted exploitation.
A web application firewall with rate limiting in front of all public endpoints. As well as blocking common attacks, this lets us blunt exploitation of a known issue while a proper fix is being prepared.
How we assess what we find
Every finding is assessed on two things: how severe it is, and whether it is genuinely exploitable in our architecture. The question that decides priority is not the generic vendor score but whether the affected code path is reachable in our deployment at all, and with what privileges. A high scoring vulnerability in a component we use only in our test tooling is not the same risk as a moderate one on a live path.
How quickly we act
Security findings are triaged into three categories on the same scale as any other service disruption, so a vulnerability and an ordinary defect run through one process rather than two. The categories, applied to security findings, are:
Critical: exploitable against production without an account, or would allow access across customer boundaries, escalation to administrator rights, or remote code execution.
Significant: exploitable only with an account or under unusual conditions, or a high severity finding in a component whose affected path is reachable in production.
Low: the affected path is not reachable in our deployment, or the component is confined to development, test or tooling environments.
Each category carries a committed reaction time and a resolution target. Alongside that:
Critical fixes are released outside the routine weekly cycle. The delivery path and all of its test gates stay the same; only the scheduling changes.
For critical and significant findings we put a workaround in place where possible until the final fix ships. For a security issue that may be a protective control such as a firewall rule, a rate limit, or temporarily disabling the affected function, rather than a code change.
If a finding cannot be resolved within the target, we tell affected customers without undue delay and give an expected timeframe.
The specific reaction and resolution times that apply to your organisation are set out in your agreement, because service levels differ between contracts. Ask your account manager and we will confirm the figures that apply to you.
How updates and components are managed
We deliberately do not adopt brand new versions of third-party components the moment they appear. A newly published version has to mature before we will pick it up, which is our main protection against a compromised or hastily withdrawn release entering our supply chain. Critical security fixes are exempt from that wait and are released out of band.
Beyond that:
Updates are approved by a person by default. They are listed for review, approved explicitly, and only then prepared as a change that must pass every automated check and be reviewed before it is merged. Updates are not applied silently.
Automatic merging is limited to small updates in areas that cannot affect how the platform behaves in production, such as test tooling and development utilities.
Major version upgrades are always separated so they remain a deliberate, isolated decision rather than something that happens in passing.
How an update reaches production
Every security fix travels exactly the same route as any other change, which is why the strength of that route is itself a security control.
Development, test and production systems are separate. A change moves through a fixed sequence of environments and cannot skip a stage.
Automated checks run before anything is merged: code linting, type checking, unit tests, authorisation test suites, and automated end-to-end tests against a production-like environment.
Human review is mandatory for any change touching authentication, authorisation, separation between customers, the data model, data migrations, infrastructure, or the handling, retention or deletion of personal data. For our backend this is enforced technically by the platform, not left to habit.
Infrastructure is managed as code. Before an infrastructure change is applied to production, the exact difference it will make is calculated and reviewed.
Deployments are versioned and reversible. A faulty change is corrected by shipping a fix through the same automated pipeline. Failed infrastructure updates roll back to their previous state. Data recovery is a separate mechanism: point-in-time recovery covers the preceding 35 days.
Everything is traceable. Every change in production can be traced back to a ticket, a commit, a reviewer and a pipeline run.
Downtime, and how you hear about changes
Routine releases, including security patches, need no planned downtime, so there is no recurring maintenance window you have to work around.
Changes carrying more risk are scheduled into periods of lower usage.
Changes that alter how you or your users work with the platform are announced by email in advance, with more lead time the more significant the change.
Smaller improvements are collected into a recurring product update email and appear in our public change log.
What we can share on request
Some detail is not published, either because it would help an attacker or because it varies by contract. Available to customers and prospects on request:
the reaction and resolution times that apply to your agreement
our technical and organisational measures in full
ISO/IEC 27001 certificates for our cloud infrastructure providers
information about our security testing and audit activity
answers to a specific security questionnaire
Contact your account manager or [email protected].