The Cyber Resilience Act and Course-Evaluation Software: When Your Feedback Platform Becomes a Product with Digital Elements

Most procurement checklists for course-evaluation software stop at GDPR, ISO 27001, and maybe NIS2. A newer EU regime is now phasing in that changes the question from "how does this vendor handle our data" to "is the software itself a secure product" — and whether it applies to your feedback platform is a genuinely subtle call that most buyers are getting wrong in both directions.

The short answer: The Cyber Resilience Act (Regulation (EU) 2024/2847) imposes cybersecurity obligations on "products with digital elements" placed on the EU market — secure-by-design development, vulnerability handling across the lifecycle, and CE marking. A pure cloud-hosted, software-as-a-service course-evaluation platform is generally outside the CRA's direct scope, but the boundary is thin: on-premise components, downloadable agents, mobile apps, and "remote data processing" integral to a product can pull a vendor in, and the CRA reshapes the whole software supply chain your vendor depends on either way. For a quality-assurance officer, the practical takeaway is not "panic" but "ask the right questions" — because the CRA's underlying discipline is exactly what you want from any platform holding sensitive student feedback.

What the CRA is, and when it bites

The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027, with the vulnerability- and incident-reporting obligations arriving earlier, from 11 September 2026 (European Commission, CRA summary). It establishes harmonised cybersecurity requirements for products with digital elements made available on the Union market. Manufacturers must build security in by design, manage vulnerabilities throughout the product lifecycle, provide documentation, and affix the CE marking to demonstrate conformity (European Commission, Cyber Resilience Act). From September 2026, actively exploited vulnerabilities and severe incidents must be reported — within tight deadlines — to ENISA and national CSIRTs.

The scope question is where course-evaluation buyers need to be careful. Software offered purely as a SaaS distribution model is, as a rule, not covered by the CRA — unless it qualifies as a "remote data processing solution." Legal analysts describe this as a genuinely fine line (DLA Piper, "Cyber Resilience Act: the fine line between SaaS and digital products," 2026). "Remote data processing" means processing carried out remotely, where that processing is essential to the product's functioning and is delivered by software developed by or for the manufacturer of the product. The Regulation's own logic is that cloud functionality integral to a product (the classic example is a smart-home device you control via the vendor's cloud) is captured, whereas cloud services designed and developed outside the responsibility of a product manufacturer are not.

What this means for a course-evaluation platform

Translate that into feedback software and the picture is nuanced:

• A browser-based, fully cloud-hosted evaluation platform with no downloadable component is, in most readings, outside the CRA's direct product scope — it is a service, not a product with digital elements.
• A downloadable mobile app, an on-premise connector, a desktop client, or an LMS/SIS integration plugin the vendor ships is software placed on the market, and is far more likely to be in scope. Many evaluation vendors ship exactly these.
• Even a wholly out-of-scope SaaS vendor is not untouched. The CRA reshapes the entire software supply chain — the libraries, components, and third-party products your vendor builds on will increasingly carry CRA conformity obligations, and a responsible vendor should be tracking that.

So the intellectually honest position — the one to bring to a procurement panel — is: do not assume the CRA applies, and do not assume it does not. Ask the vendor to state, in writing, which of their components (if any) they consider "products with digital elements," how they handle vulnerabilities and coordinated disclosure, and how they are preparing for the 2026 reporting obligations and 2027 full application. A vendor who cannot answer is telling you something regardless of whether the CRA formally binds them.

Where Koji fits

The deeper point is that the CRA is codifying practices a course-evaluation platform holding sensitive, sometimes special-category, student feedback should already follow. Koji for Education is built around EU-appropriate, GDPR-compliant data handling, and the security discipline the CRA formalises — secure-by-design engineering, structured vulnerability management, and a coordinated disclosure posture — is the standard buyers should hold any feedback vendor to, in-scope or not.

For a quality-assurance or IT-governance officer, Koji's value here is that it is designed to be answerable: the questions the CRA prompts (which components are products, how vulnerabilities are handled, how the supply chain is monitored) are the questions Koji expects a serious institution to ask. Because feedback data — free-text comments that can carry health, wellbeing, or safeguarding disclosures — is among the most sensitive an institution processes, the security posture is not a compliance box but a duty of care. Koji does not claim CRA "certification" as marketing; the CRA's conformity mechanisms are still bedding in, and any vendor claiming a finished CRA badge in 2026 should be treated with suspicion. The honest claim is that Koji is architected to meet the discipline the CRA is making mandatory.

Institutions that also run wider research on the main koji.so platform benefit from the same security engineering across their broader feedback estate, keeping governance consistent.

But isn't this just another compliance regime to ignore until 2027?

The fair objection is that the CRA is not yet fully in force, its scope for SaaS is arguably narrow, and QA officers already drowning in GDPR, the EU AI Act, NIS2, and the Data Act could reasonably deprioritise it. Why add a fifth acronym to a procurement checklist that already spans pages?

Because two of the CRA's teeth arrive before full application. The vulnerability- and incident-reporting duties start in September 2026, so any in-scope component your vendor ships is affected well before 2027. And the supply-chain effect is immediate: even out-of-scope SaaS vendors depend on components whose makers are now subject to the CRA, which changes the security assurances a diligent buyer can — and should — demand today. The honest limitations cut the other way too: for a pure-SaaS evaluation platform the CRA may impose no direct obligation at all, and a vendor pretending otherwise to sell you a "CRA-compliant" badge is overselling. The mature stance is neither alarm nor dismissal but precision: understand exactly where the boundary falls for the specific product you are buying, hold every vendor to the underlying security discipline regardless of formal scope, and treat clear, documented answers as a proxy for the seriousness of the engineering behind the platform. For software that holds your students' most candid words, that is not gold-plating — it is the floor.

Frequently asked questions

Does the Cyber Resilience Act apply to cloud-based course-evaluation software?

Generally, a pure software-as-a-service platform is outside the CRA's direct scope, because it is a service rather than a "product with digital elements." However, downloadable apps, on-premise components, integration plugins, or "remote data processing" integral to a product can bring a vendor into scope, so the answer depends on the specific product architecture.

When does the CRA take effect?

The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027. Crucially, vulnerability- and incident-reporting obligations apply earlier, from 11 September 2026, so in-scope components are affected before full application.

What should we ask an evaluation vendor about the CRA?

Ask which of their components (if any) they treat as products with digital elements, how they handle vulnerabilities and coordinated disclosure, how they are preparing for the 2026 reporting duties, and how they monitor CRA obligations flowing through their software supply chain. Clear written answers indicate serious engineering regardless of formal scope.

How is the CRA different from NIS2 and GDPR for course evaluation?

GDPR governs how personal data is handled; NIS2 imposes security and reporting duties on certain essential and important entities; the CRA regulates the security of products with digital elements themselves, including secure-by-design development and CE marking. They overlap but ask different questions, and a thorough procurement process considers all three.

Should we wait until 2027 to worry about the CRA?

No. Reporting obligations begin in September 2026, and the CRA already reshapes the software supply chain your vendor depends on. Even where it imposes no direct obligation on a SaaS platform, the underlying security discipline it formalises is what any buyer should demand of a vendor holding sensitive student feedback.