Legi versiunea produsului de componente, observații de securitate, persoane responsabile și documentație. Urmărești remedierea și verificarea în contextul versiunii afectate.
Instrument de suport, nu garanție de conformitate.
O constatare devine utilă când echipa știe ce produs și ce versiune sunt afectate. Păstrează sursa, componenta, investigația, intervenția și verificarea rezultatului. Reperele de mai jos ajută la organizarea muncii; nu certifică securitatea produsului.
| Reper | Ce pregătești sau verifici | Întrebarea de lucru |
|---|---|---|
| Produs și versiune | Identifică versiunea distribuită, componentele relevante, funcțiile și rolul companiei. Păstrează legătura cu documentația corespunzătoare. | La ce versiune se referă constatarea? |
| Vulnerabilitate și impact | Separă semnalarea de confirmarea afectării produsului. Notează sursa, datele cunoscute, impactul și informațiile care mai trebuie obținute. | Componenta există și este afectată în acest context? |
| Remediere și verificare | Desemnează responsabilul, documentează intervenția și testul efectuat. Păstrează versiunile acoperite și situațiile încă deschise. | Ce rezultat verificabil a produs intervenția? |
Nu se poate decide doar din eticheta „SaaS” sau „aplicație”. Art. 2 și art. 3 pct. 1–2 din CRA cer analiza produsului, conexiunii de date și a eventualei soluții de prelucrare la distanță necesare funcțiilor sale. Contează și condițiile punerii la dispoziție pe piață, rolul organizației și excluderile. Descrie arhitectura și funcțiile înainte de concluzie.
Da. Art. 14 și art. 71 alin. (2) din CRA prevăd raportarea de către producători, din 11 septembrie 2026, a vulnerabilităților exploatate activ și a incidentelor severe care afectează securitatea produsului, în condițiile normei. Aplicarea generală este din 11 decembrie 2027. O evidență internă nu înlocuiește raportarea cerută și nici confirmarea transmiterii ei.
Revizuit la . CRA: Regulamentul (UE) 2024/2847, forma consolidată la 20 noiembrie 2024; art. 2–3, 13–14 și 71. Organizarea documentației și remedierea tehnică sunt activități distincte. Cerințele se verifică pentru rolul, produsul și data relevante.
Un produs fictiv și o observație asupra unei componente. Exemplul nu decide aplicabilitatea CRA și nu efectuează o remediere.
Produsul, rolul organizației și versiunea se identifică separat. Componentele și materialele se leagă de acea versiune.
Aplicabilitatea se analizează pentru produs și rol; nu este atribuită automat oricărui SaaS.
Date fictive. Schimbarea perspectivei explică procesul; nu înregistrează operațiuni în aplicație.
Activitatea și rezultatul rămân legate de context, de oamenii implicați și de materialele pe care te bazezi.
Fiecare material își păstrează contextul tehnic relevant.
Informația primită și rezultatul intervenției sunt repere distincte.
Documentația explică schimbarea și ce rămâne de urmărit.
Spune-ne cum lucrați acum și unde ai nevoie de sprijin.