ISO megfelelés és auditálhatóság fejlesztőknek

Egy kis csapat által épített szoftver (Supabase, Next.js, Vercel, edge function, AI ügynök, MCP szerver) kontrollokkal és bizonyítékokkal járul hozzá egy ISO szintű audithoz. A technikai védelmek részletei a társ kézikönyvekben vannak, ez a kézikönyv a megfelelési oldalt adja hozzájuk. Sorra vesszük, melyik kontroll mit kér egy kis projekttől, milyen nyom bizonyítja a működését, hol érdemes tárolni, és hogyan épül be mindez a napi fejlesztési munkába.

A szabványok szövege jogvédett. Emiatt a kontrollok lényege saját megfogalmazásban szerepel, a szám és a cím csak a hivatkozást szolgálja, a konkrét követelményt a megvásárolt szabványból kell ellenőrizni. Semmi sem minősül itt jogi tanácsnak vagy tanúsítási garanciának. Tanúsítványt az akkreditált tanúsító szervezet ad ki az auditja alapján, a jogszabályi hatályt pedig jogász állapítja meg.

A technikai részletek a kapcsolódó kézikönyvekben találhatók.

0. Alapállítás. A tanúsítvány a szervezeté, nem a szoftveré

Az ISO/IEC 27001 egy szervezet információbiztonsági irányítási rendszerét (ISMS) tanúsítja, egy írásban rögzített hatókörre. Szoftverterméket 27001 szerint nem lehet tanúsítani, és egy repó önmagában sem lehet ISO megfelelő. A szoftver két úton számít az auditban. Egyrészt a benne és körülötte megvalósított kontrollokkal (hozzáférés, naplózás, titkosítás, biztonságos fejlesztés), másrészt azokkal a bizonyítékokkal, amelyeket a fejlesztési folyamat termel (PR előzmények, CI naplók, scan riportok, mentési próbák jegyzőkönyvei). Ugyanez igaz a 27701, a 42001, a 9001 és a 22301 szabványra, mert mindegyik irányítási rendszert ír le, nem terméket.

Három gyakorlati következmény adódik ebből.

1. Ha az ügyfél ISO megfelelő szoftvert kér, előbb tisztázni kell, mit ért alatta. Lehet, hogy a szoftver az ügyfél saját ISMS-ének hatókörébe kerül, ekkor az ő kontrolljait kell támogatni és nekik bizonyítékot szállítani. Másik eset, hogy a fejlesztő cégtől vár tanúsítványt, ekkor a fejlesztő szervezet ISMS-ét kell felépíteni, és a szoftverfejlesztés ennek egyik folyamata.
2. Termékszintű megfelelőség más eszközökkel létezik. Ilyen a Common Criteria (ISO/IEC 15408), a Cyber Resilience Act szerinti CE jelölés, vagy egyes ágazati sémák. A 27001 nem ilyen.
3. Az audit a működés nyomát keresi. Egy szabályzat, amelyet senki nem követ, nem megfelelőség. Nyom nélkül a jól működő gyakorlat sem létezik az auditor szemében.

1. A szabványok állapota 2026 októberében

A verziók évente változnak. Projektkezdéskor és audit előtt az iso.org katalógusában érdemes ellenőrizni az aktuális kiadást.

2. ISO/IEC 27001:2022 felépítése és a tanúsítás menete

2.1 A 4-10. klauzula és a PDCA

A 27001 a harmonizált szerkezetet (régi nevén Annex SL) követi, ezért a 9001, a 27701, a 42001 és a 22301 klauzulái ugyanott vannak. Egy integrált irányítási rendszer emiatt sok dokumentumot közösen használhat. Az 1-3. klauzula hatály, hivatkozás és fogalmak, követelményt a 4-10. klauzula tartalmaz.

PDCA leképezés. Plan a 4-6. klauzula, Do a 7-8., Check a 9., Act a 10. Egy kis cégnél a ciklus jellemzően éves, a kockázatértékelés és a hozzáférés felülvizsgálat ennél sűrűbb.

Klímamódosítás (Amd 1:2024). Két mondat került be. A 4.1 szerint a szervezet megállapítja, hogy a klímaváltozás releváns tényező-e, a 4.2 megjegyzése szerint az érdekelt feleknek lehetnek klímával kapcsolatos elvárásai. Egy felhőben futó SaaS-nál ez általában egy indokolt bekezdés a környezetelemzésben (adatközponti régió, hőség okozta szolgáltatáskiesés, ügyféloldali ESG elvárás). A kihagyása viszont tipikus kisebb megállapítás.

2.2 Kötelező dokumentált információk a 27001 szerint

A szabvány két fajtát különböztet meg. Fenntartandó dokumentált információ a szabályozó dokumentum (szabályzat, eljárás), megőrzendő pedig a bizonyíték (record). Az alábbi lista a klauzulák alapján készült, saját összefoglalásban.

Az A melléklet kontrolljai közül több is dokumentumot vár (például 5.1 politikák, 5.9 leltár, 5.31 jogszabályi követelmények, 5.37 dokumentált üzemeltetési eljárások). Ezek a szabvány szerint nem minden esetben kötelezők, de az auditorok szinte mindig keresik őket.

2.3 A tanúsítás menete

1. Tanúsító választása. Akkreditált tanúsító kell, Magyarországon a Nemzeti Akkreditáló Hatóság (NAH) által vagy más, a nemzetközi kölcsönös elismerésben részt vevő akkreditáló testület által akkreditált. Nem akkreditált tanúsítvány nagyvállalati beszállítói minősítésnél jellemzően nem elég. A tanúsítvány érvényessége a tanúsító nyilvános adatbázisában és az IAF CertSearch felületen ellenőrizhető.
2. Stage 1. Dokumentációs és felkészültségi átvizsgálás, gyakran távolról. Az auditor a hatókört, a kockázatkezelési módszert, a SoA-t, a politikát, a belső auditot és a vezetőségi átvizsgálást nézi, és azt, hogy a szervezet készen áll-e a Stage 2-re. Kimenete egy lista azokról a hiányokról, amelyek a Stage 2-n nem megfelelőséggé válhatnak.
3. Stage 2. A működés értékelése. Interjúk, mintavétel, rendszerek megtekintése képernyőmegosztással. A Stage 1 és a Stage 2 között jellemzően néhány hét telik el, ennyi idő jut a javításra.
4. Tanúsítási döntés. A megállapítások lezárása (major esetén a javítás igazolása) után a tanúsító független döntéshozója dönt. A tanúsítvány három évig érvényes.
5. Felügyeleti auditok. Az első és a második évben, az elsőt a Stage 2 utáni tizenkét hónapon belül. Rövidebbek, a kontrollok egy részét mintázzák, de a belső auditot, a vezetőségi átvizsgálást és a korábbi megállapítások lezárását mindig nézik.
6. Újratanúsítás. A harmadik év végén, a lejárat előtt, teljes körű.

Audit időtartama. Az auditnapok számát a tanúsító az ISO/IEC 27006-1:2024 és a kapcsolódó akkreditációs szabályok alapján, főleg a hatókörbe tartozó létszám és a komplexitás szerint számolja. Egy 1-5 fős szoftvercégnél a kezdeti tanúsítás (Stage 1 és Stage 2 együtt) nagyságrendileg néhány auditornap, a felügyeleti audit ennek körülbelül harmada. A konkrét számot az árajánlat tartalmazza.

2.4 Mit néz az auditor

Az auditor nem a kódot olvassa, hanem azt ellenőrzi, hogy a leírt folyamat működik, és a kockázatokra adott válasz hatásos. Négy forrásból dolgozik.

• Dokumentált információ. Szabályzatok, eljárások, SoA. Azt nézi, hogy jóváhagyottak, verziózottak, aktuálisak, és egymásnak nem mondanak ellent.
• Records. A működés nyoma. PR jóváhagyás, CI futás, hozzáférés felülvizsgálat jegyzőkönyve, visszaállítási próba, képzési jelenlét, incidensnapló. Egy dátumozott, módosíthatatlan nyom többet ér bármilyen állításnál.
• Interjú. Megkérdezi a fejlesztőt, mit csinál, ha egy kritikus sebezhetőség jelenik meg egy függőségben, vagy ki tud éles adatbázishoz hozzáférni. A válasznak egyeznie kell a dokumentummal és a nyommal.
• Mintavétel és megfigyelés. Kiválaszt például öt összevont PR-t a negyedévből, és végigköveti a jegyről a jóváhagyáson és a CI-on át a deployig. Egy kilépett munkatársnál vagy alvállalkozónál azt nézi meg, mikor vonták vissza a GitHub, a Supabase és a Vercel hozzáférését. A Supabase felületen a mentési beállítást is megnyithatja.

A tipikus auditnyom egy szálon fut végig. Az auditor a kockázatregiszter egy sorából a SoA egy kontrolljához jut, onnan a kontrollt megvalósító eljáráshoz, végül az eljárás működését igazoló recordhoz. Ha a szál bárhol megszakad, ott lesz a megállapítás.

2.5 Nem megfelelőségek

A válaszban három dolgot kell szétválasztani. Javítás (correction) az azonnali hibaelhárítás, például a hozzáférés visszavonása. A gyökérok elemzése megmondja, miért történt (nincs kilépési checklist). Helyesbítő intézkedés (corrective action) az, ami a megismétlődést akadályozza meg (kilépési checklist és havi automatikus hozzáféréslista összevetés). Gyökérok és helyesbítő intézkedés nélkül a javítás nem zárja le a megállapítást.

3. Az A melléklet kontrolljai fejlesztői szemmel (ISO/IEC 27002:2022)

A 2022-es kiadás 93 kontrollja négy témába rendeződik. Szervezeti kontrollok (5.1-5.37, 37 darab), személyi kontrollok (6.1-6.8, 8 darab), fizikai kontrollok (7.1-7.14, 14 darab) és technológiai kontrollok (8.1-8.34, 34 darab). Tizenegy kontroll új a 2013-as kiadáshoz képest, ezek közül fejlesztést érint az 5.7, 5.23, 5.30, 8.9, 8.10, 8.11, 8.12, 8.16 és 8.28. Minden kontrollhoz a 27002 attribútumokat is rendel (kontroll típusa, érintett biztonsági tulajdonság, kiberbiztonsági fogalom a NIST CSF szerint, működési képesség, biztonsági terület), ezek segítenek a SoA szűrésében és a NIST CSF leképezésben.

A táblázatokban a kontroll címe saját rövidítésben szerepel, a lényeg saját megfogalmazás. Az utolsó oszlop azt a projektszintű compliance dokumentumot nevezi meg, amelyben a bizonyíték él (a teljes dokumentumkészlet a kézikönyv végén, A gyakorlatban alatt szerepel). Ahol szervezeti szintű dokumentum kell, ott a szervezeti ISMS szerepel, ami a cég közös ISMS repóját vagy mappáját jelenti.

3.1 Szervezeti kontrollok

3.2 Személyi kontrollok

A 6.3 a leggyakrabban hiányzó bizonyíték. Egy kis cégnél elég egy évente frissített, egyórás belső anyag és a résztvevők listája, de dátummal és tartalommal.

3.3 Fizikai kontrollok

A 7.1-7.14 kontrollok nagy részét felhőalapú, irodát nem fenntartó cégnél a beszállító teljesíti (adatközponti fizikai védelem), ezt a SoA-ban a beszállító SOC 2 vagy ISO tanúsítványára hivatkozva lehet indokolni. Ettől még a fizikai téma egésze nem zárható ki. Saját felelősség marad a 7.7 (tiszta asztal, zárolt képernyő), a 7.9 (eszközök a telephelyen kívül, laptop otthon és úton), a 7.10 (adathordozók, pendrive és mentési lemez) és a 7.14 (eszköz biztonságos selejtezése vagy újrahasznosítása). Technikai megvalósítás a teljes lemeztitkosítás (FileVault, BitLocker), az automatikus képernyőzár, és a selejtezési jegyzőkönyv.

3.4 Technológiai kontrollok

3.5 A kiemelt fejlesztési kontrollok részletesebben

8.4 Forráskód. A forráskód hozzáférés két irányú kockázat. Ha kiszivárog, kiderülnek a belső logikák és az esetleg benne maradt titkok. Jogosulatlan írásnál pedig valaki a buildbe nyúlhat. A kontroll ezért a repón túl a CI-t, a deploy kulcsokat és a csomagregisztert is lefedi. Gyakorlatban privát repó, legfeljebb két owner, írási jog csak a csapat tagjainak, védett main ág, aláírt commitok ahol a csapat bírja, GitHub Actions permissions minimálisra szűkítve, Vercel és Supabase integráció tokenje a legszűkebb szkóppal. Az AI kódoló eszköz is hozzáférő. Ha egy AI asszisztens vagy ügynök írási jogú tokennel dolgozik, annak szerepelnie kell a hozzáférési listában, a jogának szűknek kell lennie, és a munkájának review-n kell átmennie.

8.8 Sebezhetőségek. A scanner futtatása önmagában kevés. Az auditor a lezárási időt keresi a vállalt SLA-hoz képest, és a kivételek kezelését (ha egy sebezhetőséget nem javítanak, ki és miért fogadta el a kockázatot, meddig). Forrásai a Dependabot és az npm audit, a Supabase security advisor, a semgrep, a külső bejelentés (security.txt, a CRA alá tartozó terméknél kötelező koordinált sebezhetőség közzétételi szabály), és a beszállítók biztonsági közleményei. SLA javaslat a 9.7 pontban szerepel.

8.9 Konfigurációkezelés. A felhő konfiguráció a kattintgatás miatt szokott elcsúszni. Ami lehet, kódként él (supabase/config.toml, migrációk, RLS policyk SQL-ben, vercel.json, GitHub ruleset JSON), a többiről dátumozott export vagy képernyőkép készül. Az eltérés észlelésére a Supabase advisors rendszeres futtatása és a GitHub ruleset rendszeres exportja szolgál, mert egy kikapcsolt védelem csak így válik láthatóvá.

8.10, 8.11, 8.12 Törlés, maszkolás, szivárgás. Ez a hármas a GDPR adattakarékossági és tárolási korlátozás elvének technikai oldala. Megőrzési idő mezőnként vagy táblánként, ütemezett törlés, és a törlés futásának naplója. Maszkolás ott, ahol a fejlesztő vagy a support nem szorul a valódi adatra. Szivárgásmegelőzés a titokscan (gitleaks a CI-ban és pre-commit hookként), a naplók redakciója, és LLM funkciónál a kimeneti szűrés.

8.15 és 8.16 Naplózás és monitorozás. A Supabase és a Vercel saját naplómegőrzése csomagtól függően napokban mérhető, ez egy évre visszanyúló auditnyomhoz kevés. A biztonsági eseményeket (bejelentkezés, jogosultságváltozás, admin művelet, export, kulcshasználat) alkalmazásszintű audit táblába vagy log drainen át külső tárba kell vinni, megőrzési idővel. Monitorozás akkor bizonyítható, ha van riasztási szabály, és van legalább egy kezelt riasztás nyoma. A technikai részletek a Kiberbiztonság kézikönyv naplózásról szóló szakaszában vannak.

8.24 Kriptográfia. A szolgáltatói titkosítás (Supabase és Vercel tárolt adat titkosítás, TLS) a SoA-ban beszállítói hivatkozással indokolható. Saját felelősség a kulcsok leltára és rotációja (Supabase API kulcsok, JWT titok, LLM kulcsok, Stripe webhook titok), az alkalmazásszintű titkosítás döntése az érzékeny mezőkre, és a tiltott algoritmusok listája. A kulcsleltárban csak a kulcs neve, helye, tulajdonosa és rotációs dátuma áll, maga a titok soha.

8.25 és 8.26 SDLC és követelmények. A 8.25 egy leírt fejlesztési életciklust vár, amelyben a biztonság lépésenként megjelenik. Egy kis csapatnál ez egy oldal. Spec és fenyegetésmodell, kód és önátnézés, PR review, CI kapuk, release checklist, élesítés utáni ellenőrzés. A 8.26 azt kéri, hogy a biztonsági követelmény a funkcionális követelmény mellett szerepeljen. Erre az ASVS kijelölt szintje a legolcsóbb forrás, a követelményekhez rendelt ASVS azonosítók pedig a követelmény nyomonkövetési mátrixban követhetők.

8.27 Architektúra elvek. Elég egy rövid elvlista (legkisebb jogosultság, alapból tiltás, mélységi védelem, fail closed, bizalmi határok jelölése, titok csak szerveren, LLM kimenet nem megbízható bemenet), és az ADR-ek, amelyek mutatják, hogy a döntéseknél ezeket alkalmazták.

8.28 Biztonságos kódolás. Az új kontroll a kódolási szabályt, a külső és nyílt forrású komponensek kezelését és a kód ellenőrzését fogja össze. AI asszisztált fejlesztésnél az auditor egyre gyakrabban rákérdez, mi a szabály az AI által generált kódra. Elfogadható válasz egy leírt szabály (AI generált kód is csak review után kerül be, a tiltott minták listája rá is vonatkozik, a csomagjavaslatot ellenőrizni kell), és a betartás nyoma (review kommentek, SAST riport).

8.29 Biztonsági tesztelés. Funkcionális tesztekből a biztonsági teszt nem következik. Kell legalább egy RLS és tenant izolációs tesztkészlet (más felhasználó adatát nem látja, anonim nem ír), authz tesztek a szerveroldali végpontokra, és nagyobb kiadás előtt vagy évente külső pentest. LLM funkciónál ide tartozik a prompt injection és a kimenet validálás tesztje (lásd az AI ügynökök és vibecoding kézikönyvet).

8.31, 8.32, 8.33 Környezetek, változás, tesztadat. Részletesen a 9.2 és 9.3 pontban. A leggyakoribb kis cégnél tapasztalt hiba, hogy a preview környezet az éles adatbázisra mutat, vagy éles adatmentés kerül a fejlesztői gépre.

8.34 Audit alatti védelem. Az auditor vagy pentester olvasási jogot kap, időablakkal, és a hozzáférés lejárta után visszavonásra kerül. A pentest megállapodás rögzíti a hatókört, a tiltott technikákat és a kapcsolattartót.

4. Statement of Applicability és kockázatkezelés

4.1 Kockázatkezelési módszer kis szervezetre (27005:2022 és 31000:2018)

Az ISO 31000 elveket és folyamatot ad (kontextus, azonosítás, elemzés, értékelés, kezelés, monitorozás, kommunikáció), a 27005 ezt az információbiztonságra fordítja. A 2022-es 27005 két egyenrangú azonosítási utat ír le. Az esemény alapú út stratégiai forgatókönyvekből indul (például kiszivárog az ügyfelek adata), a vagyonelem alapú pedig a leltár elemeiből, azok fenyegetéseiből és sérülékenységeiből. Kis csapatnak az esemény alapú megközelítés a gyorsabb, a fenyegetésmodellből (Kiberbiztonság, fenyegetésmodellezés) jövő forgatókönyvekkel kiegészítve.

A módszertan dokumentumnak öt dolgot kell rögzítenie.

1. Skálák. Valószínűség 1-5 és hatás 1-5, szöveges leírással minden szintre (a hatásnál pénz, ügyfélszám, jogi következmény, rendelkezésre állás szerint).
2. Kockázati szint. Valószínűség szorozva hatással, sávokkal (például 1-6 alacsony, 7-14 közepes, 15-25 magas).
3. Elfogadási kritérium. Mi fogadható el kezelés nélkül (például 6 alatt), és ki fogadhatja el (a kockázat gazdája, magas szintnél az ügyvezető).
4. Kezelési lehetőségek. Csökkentés kontrollal, elkerülés (a funkció elhagyása), megosztás (biztosítás, szerződés, beszállító) és tudatos megtartás.
5. Gyakoriság. Teljes felülvizsgálat évente, eseti felülvizsgálat jelentős változásnál (új adatkategória, új beszállító, új AI funkció, incidens után).

A regiszter egy sora így néz ki.

A lethal trifecta (privát adat, nem megbízható tartalom és kifelé vezető csatorna együtt egy ügynökben) megszakításáról az AI ügynökök és vibecoding kézikönyv ír részletesen. A regisztert gitben tartjuk, így a verziótörténet maga a 8.2 szerinti rendszeres értékelés bizonyítéka.

4.2 A Statement of Applicability

A SoA a 27001 6.1.3 d pontja szerinti dokumentum. Mind a 93 kontrollra megmondja, szükséges-e, miért, megvalósult-e, és ha nem szükséges, miért zárták ki. Az auditor a SoA-ból indul, ezért ennek kell a legmegbízhatóbbnak lennie.

Kis szervezetre szabott szabályok.

• Kizárás csak indokkal. Egy kontroll akkor zárható ki, ha a kockázatok alapján nem szükséges, nem azért, mert kényelmetlen. Az 5.x és 8.x kontrollok közül egy szoftvercégnél szinte semmi nem zárható ki.
• Beszállítóra hivatkozás. Ha a kontrollt a felhőszolgáltató teljesíti, a SoA erre hivatkozik, és a beszállítói nyilvántartásban ott a tanúsítvány vagy a SOC 2 riport dátuma. A közös felelősség saját fele (például az RLS beállítása) ettől a mi feladatunk marad.
• Projektszintű kivonat. A szervezet egyetlen SoA-t tart. A projekt SoA kivonata ennek egy szelete, csak a projektre jellemző megvalósítással és bizonyítékhivatkozással, hogy a szervezeti SoA egy sora több projektből is kapjon bizonyítékot.

5. Adatvédelem és felhő. 27701, GDPR, 27017, 27018

5.1 ISO/IEC 27701:2025 és a GDPR

A 2025 októberében megjelent kiadás önálló irányítási rendszer szabvánnyá tette az adatvédelmi irányítási rendszert (PIMS). Saját 4-10. klauzulája van, és már nem a 27001 kiterjesztése, tehát 27001 tanúsítvány nélkül is tanúsítható. Az A melléklet külön kontrollkészletet ad az adatkezelőknek és az adatfeldolgozóknak, emellett a biztonsági kontrollokat is tartalmazza. Aki 27001 mellett vezeti be, a közös klauzulákat integráltan kezelheti.

Kapcsolat a GDPR-ral. A 27701 jól leképezhető a GDPR cikkeire, és a szabvány tartalmaz is ilyen leképezést. Egy 27701 tanúsítvány nem a GDPR 42. cikke szerinti, hatóság vagy EDPB által jóváhagyott adatvédelmi tanúsítás, tehát nem bizonyítja a GDPR megfelelést. Arra jó, hogy egy auditált, működő adatvédelmi rendszert mutasson az ügyfélnek és a hatóságnak.

Fejlesztői oldalon a 27701 és a GDPR ugyanazokat a tárgyakat kéri (részletesen az Adatbiztonság és adatvédelem kézikönyv GDPR szakaszában).

5.2 ISO/IEC 27017:2026 és 27018:2025

A 27017 a 27002 kontrolljaihoz ad felhőspecifikus útmutatót, külön a felhőszolgáltatónak és a felhőt igénybe vevőnek, és néhány saját felhőkontrollt is meghatároz. Második kiadása 2026 júliusában jelent meg, és a 27002:2022 szerkezetéhez igazodik. Egy kis szoftvercég kettős szerepben van. Supabase és Vercel felé ügyfél, a saját SaaS terméke felől pedig szolgáltató az ügyfelei felé. Mindkét irányban a közös felelősség megosztását kell leírni.

A 27018 a nyilvános felhőben adatfeldolgozóként kezelt személyes adatra vonatkozik. Akkor releváns, ha a SaaS-unk az ügyfél munkatársainak vagy ügyfeleinek adatát dolgozza fel az ügyfél megbízásából. A 2025-ös harmadik kiadás a 27002:2022-höz igazodik, és bővített útmutatót ad egy új mellékletben. Fejlesztői következményei egyértelműek.

• Az ügyféladatot csak az ügyfél utasítása szerint használjuk. Termékfejlesztésre, marketingre vagy modelltanításra kifejezett hozzájárulás nélkül nem.
• Az alvállalkozó adatfeldolgozók (Supabase, Vercel, LLM szolgáltató, email küldő) listája nyilvános vagy az ügyfélnek átadott, változásnál értesítünk.
• Hatósági adatkérés nyilvántartása és az ügyfél értesítése, ahol jogilag lehetséges.
• Incidensnél késedelem nélküli értesítés az ügyfélnek (a szerződésben vállalt órán belül), hogy ő a 72 órás GDPR határidőt tarthassa.
• Szerződés végén az ügyféladat exportja és igazolt törlése, a mentésekből a megőrzési idő lejártával. Ehhez tenant szintű export és törlő szkript kell, a futásáról jegyzőkönyvvel.
• Ideiglenes fájlok, naplók és LLM naplók törlése meghatározott időn belül.

6. AI irányítás. ISO/IEC 42001:2023 és 42005:2025

6.1 A 42001 fő követelményei

A 42001 az első tanúsítható AI irányítási rendszer szabvány (AIMS). Ugyanazt a harmonizált 4-10. klauzulás szerkezetet követi, mint a 27001, ezért a két rendszer közös dokumentumokkal (hatókör, politika, belső audit, vezetőségi átvizsgálás) integrálható. Az AI sajátos elemei a következők. A szabvány részletes, AI specifikus tárgyalása az AI ISO szabványok kézikönyvben található.

• Szerep meghatározása (4. klauzula). A szervezet rögzíti, milyen szerepben van az AI rendszerrel kapcsolatban. Lehet AI szolgáltató (provider, aki a rendszert kínálja), AI előállító (producer, aki fejleszti), AI felhasználó (customer), partner, vagy érintett. Egy tanácsadó, aki egy kereskedelmi LLM API-ra (például a Claude API-ra) épülő ügynököt épít és ad át ügyfélnek, jellemzően előállító és szolgáltató egyszerre, a modell szolgáltatója pedig a beszállítója.
• AI politika (5.2) és felelősségek (5.3). Mire használ AI-t a szervezet, mire nem, ki felel érte.
• AI kockázatértékelés (6.1.2) és kezelés (6.1.3). A 27001 logikájával, saját SoA-val az A melléklet kontrolljaira.
• AI rendszer hatásvizsgálat (6.1.4 és 8.4). Az egyénekre, csoportokra és a társadalomra gyakorolt lehetséges hatások értékelése, dokumentáltan. Ez a 42001 legsajátosabb eleme, a tartalmát a 42005 írja le.
• Célok (6.2), működés (8), teljesítményértékelés (9), fejlesztés (10). Mint a 27001-nél, AI metrikákkal (eval eredmények, hibaarány, emberi felülbírálási arány, incidensek).

6.2 Az A melléklet kontrollterületei

A 42001 A melléklete 38 kontrollt tartalmaz kilenc célterületen. Mellette a B melléklet a megvalósítási útmutató, a C melléklet a lehetséges szervezeti célokat és kockázati forrásokat sorolja, a D melléklet az ágazati alkalmazásról szól.

6.3 AI hatásvizsgálat a 42005 szerint

A 2025 májusában megjelent 42005 útmutató, nem tanúsítható. Azt írja le, mit tartalmazzon és mikor készüljön egy AI rendszer hatásvizsgálat. A lényege saját összefoglalásban.

• Mikor. Tervezéskor, élesítés előtt, és minden jelentős változásnál (új modell, új eszköz, új adatforrás, új felhasználói kör, új cél).
• Mit ír le. A rendszert és a rendeltetését, az előre látható helytelen használatot, az érintetteket (közvetlen felhasználó és akire a kimenet hat), a felhasznált adatokat, a lehetséges előnyöket és ártalmakat (tévedés, elfogultság, magánszféra, biztonság, átláthatóság, emberi autonómia), a kezelő intézkedéseket, a maradék hatást és a monitorozást.
• Kapcsolat más vizsgálatokkal. A GDPR szerinti DPIA, a fenyegetésmodell és az AI Act szerinti alapjogi hatásvizsgálat (ahol kötelező) átfedésben van vele. Kis projektben egy dokumentumban, kereszthivatkozással érdemes kezelni, hogy ne legyen három, egymásnak ellentmondó változat.

6.4 Kapcsolat az EU AI Acttal

A határidők és a kockázati kategóriák a Digital Omnibus utáni állapottal az AI ügynökök és vibecoding kézikönyvben szerepelnek. Megfelelési oldalról három szempont tartozik ide.

• A 42001 a 2026 októberi állapot szerint nem harmonizált európai szabvány az AI Act alatt, ezért alkalmazása önmagában nem ad megfelelőségi vélelmet. Harmonizált szabványokat a CEN-CENELEC JTC 21 készít (minőségirányítás, kockázatkezelés, adatminőség, naplózás, pontosság, kiberbiztonság). Ezek várhatóan sok elemet átvesznek a 42001-ből, de a státuszuk ellenőrizendő.
• Magas kockázatú rendszer szolgáltatójánál az AI Act minőségirányítási rendszert (17. cikk), kockázatkezelési rendszert (9. cikk), műszaki dokumentációt (11. cikk és IV. melléklet) és automatikus naplózást (12. cikk) vár. Egy működő 42001 AIMS ezek nagy részéhez kész keretet és bizonyítékot ad.
• Átláthatósági kötelezettségnél (chatbot, generált tartalom) az A.8 kontrollterület és a felületen megjelenő AI jelzés a bizonyíték.

6.5 Mit dokumentál egy AI ügynök vagy LLM funkció

Minden LLM funkcióhoz, ügynökhöz és MCP szerverhez AI rendszerkártya készül. Az AI ügynökök és vibecoding kézikönyv ügynök tervezési kártyája a tervezési oldal, ez a kártya a megfelelési oldal, és a kettő hivatkozik egymásra.

Egy modellverzió csere változáskezelési esemény. Eval futtatás, eredmény a kártyában, jóváhagyás a PR-ben, és ha a viselkedés érdemben változik, új hatásvizsgálat.

7. Termékminőség, tesztelés, életciklus, minőségirányítás, folytonosság

7.1 ISO/IEC 25010:2023. A termékminőségi modell

A 2023-as kiadás kilenc jellemzőt határoz meg. Használhatóság helyett interakciós képesség, hordozhatóság helyett rugalmasság szerepel, és új jellemző lett a biztonság (safety, a károkozás elkerülése értelmében). Mindegyik kapcsolódik a Szoftverarchitektúra kézikönyvben tárgyalt minőségi attribútumokhoz. Megfelelési haszna abban van, hogy a nem funkcionális követelmények mérhető elfogadási feltétellel kerülnek a követelmény nyomonkövetési mátrixba.

7.2 ISO/IEC/IEEE 29119. Tesztdokumentáció minimum

A 29119-3 szervezeti szintű (tesztpolitika, tesztelési gyakorlat), projekt szintű (tesztterv, státusz és záró jelentés) és dinamikus tesztelési dokumentumokat (tervezési specifikáció, teszteset, tesztadat és környezet készenlét, eredmény, tesztincidens jelentés) ír le. Kifejezetten engedi a dokumentumok összevonását és agilis formáját, ennek a 29119-6 ad keretet. Egy kis projektben a minimum a következő.

LLM funkciónál a teszteset az eval készlet eleme, a teszteredmény az eval futás riportja. Az ISO/IEC TR 29119-11 az AI alapú rendszerek tesztelésének sajátosságait (nem determinisztikus kimenet, adatfüggés, metamorfikus tesztelés) tárgyalja.

7.3 ISO/IEC/IEEE 12207. Életciklus folyamatok röviden

A 12207 a szoftver életciklus folyamatainak közös szótára, nem módszertan. Négy folyamatcsoportot ír le a 2017-es kiadás, a 2026-ra várt második kiadás ezt a szerkezetet frissíti (agilis módszerek, modellalapú mérnökség, kockázat és konfigurációkezelés pontosítása).

Az auditor szempontjából a 12207 haszna a közös nyelv. Ha egy ügyfél beszállítói kérdőíve 12207 folyamatokra kérdez rá, a fenti tábla mutatja, melyik projektartefaktum felel meg nekik.

7.4 ISO 9001. Változáskezelés és dokumentált információ

A 2026 szeptemberében megjelent új ISO 9001 a 2015-ös kiadás célzott továbbfejlesztése, a folyamatszemlélet, a PDCA és a kockázatalapú gondolkodás változatlanul központi. Klauzulaszámozása a harmonizált szerkezet miatt nagyrészt megmaradt, de a konkrét pontszámokat az új szövegben ellenőrizni kell. Szoftverfejlesztést négy terület érint leginkább (a 2015-ös számozással).

• Dokumentált információ szabályozása (7.5). Azonosítás, formátum, átvizsgálás és jóváhagyás, elérhetőség, változásszabályozás, megőrzés. A git ezt szinte teljesen lefedi. Markdown dokumentum, PR alapú jóváhagyás, verziótörténet, védett ág.
• Változások tervezése (6.3). Rendszerszintű változtatás (új folyamat, új eszköz) előtt a cél, a következmény és az erőforrás mérlegelése. Ez a 27001 6.3 pontjával közös.
• Tervezés és fejlesztés (8.3). Bemenetek (követelmények), átvizsgálás, verifikáció, validáció, kimenetek és a tervezési változások kezelése (8.3.6). Ez a spec, a review, a teszt és az elfogadás nyoma.
• Változások szabályozása az előállítás során (8.5.6) és nem megfelelő kimenetek (8.7). Éles hiba esetén a kezelés, az ügyfél tájékoztatása és a helyesbítés nyoma.

Egy 9001 auditor ugyanazt a PR, review, CI és release láncot keresi, mint a 27001 auditor a 8.32-nél, csak minőségi szempontból (megfelel-e a kimenet a követelménynek). Mindkettőjüknek bizonyíték egy jól vezetett követelmény nyomonkövetési mátrix.

7.5 ISO/IEC 27034. Alkalmazásbiztonság fogalmi keret

A 27034 az alkalmazásbiztonságot szervezeti és alkalmazásszintű keretként írja le. Szervezeti normatív keret (ONF) néven tartalmazza az összes elfogadott biztonsági gyakorlatot, ebből minden alkalmazáshoz egy alkalmazás normatív keret (ANF) készül a célzott bizalmi szint szerint, és ennek elemei az alkalmazásbiztonsági kontrollok (ASC), mindegyik saját verifikációs méréssel. Gyakorlatban a csapat tiltott minták listája, az ASVS és a review checklist alkotja az ONF-et, a projekt kijelölt ASVS szintje és fenyegetésmodellje az ANF-et, egy konkrét RLS teszt vagy semgrep szabály pedig a saját ellenőrzésével együtt egy ASC. Közvetlenül ritkán auditálják, de jó indoklás a 8.25 és 8.28 közötti kontrollok megvalósítására.

7.6 ISO 22301. Üzletmenet folytonosság

A 22301 (2019, a 2024-es klímamódosítással) a BCMS követelményeit adja. Szoftverprojektet három fogalma érint.

• Üzleti hatáselemzés (BIA). Mely tevékenységek kritikusak, mennyi kiesés tűrhető el (maximálisan tűrhető kiesési idő, MTPD), és mi a minimális elfogadható szolgáltatási szint.
• RTO (helyreállítási idő cél). Mennyi idő alatt kell a szolgáltatásnak újra működnie. Kisebb az MTPD-nél.
• RPO (helyreállítási pont cél). Mennyi adatvesztés fogadható el időben mérve. Supabase PITR mellett ez percekben mérhető, napi mentésnél akár 24 óra.

Gyakorlati BIA egy kis SaaS-nál egyetlen táblázat. Szolgáltatásonként (bejelentkezés, fő funkció, AI funkció, fizetés, admin) a kiesés hatása óránként és naponta, a vállalt RTO és RPO, a függőségek (Supabase, Vercel, LLM szolgáltató, Stripe, DNS), és a kerülőút (degradált mód, kézi feldolgozás). Gyakori rejtett függőség a DNS regisztrátor fiókja, az egyetlen ember telefonjához kötött MFA és a lejáró domain. A visszaállítási próba (9.6) igazolja, hogy a vállalt RTO és RPO valós. A mentés és a helyreállítás technikai részletei az Adat és adatbázisok kézikönyvben vannak.

8. Gyakran együtt kért keretek

8.1 SOC 2 és a Trust Services Criteria

A SOC 2 az AICPA attesztációs jelentése, nem tanúsítvány. Független könyvvizsgáló (CPA) véleményez a szolgáltató rendszeréről a Trust Services Criteria (2017, a fókuszpontok 2022-es frissítésével) alapján. A Security kritériumcsoport (Common Criteria, CC1-CC9) kötelező, az Availability, Processing Integrity, Confidentiality és Privacy választható. Type I egy időpontra a kontrollok kialakítását, Type II egy megfigyelési időszakra (jellemzően 3-12 hónap) a működésük hatásosságát értékeli. Amerikai ügyfeleknél a SOC 2 Type II gyakoribb elvárás, európaiaknál a 27001.

A két keret kontrollszinten nagyrészt átfed, az AICPA hivatalos leképezést is közöl. Közelítő megfeleltetésük alább látható.

Ugyanaz a bizonyítékcsomag mindkettőt kiszolgálja. A különbség, hogy a SOC 2 Type II a teljes megfigyelési időszakra kér mintát, ezért a havi automatikus bizonyítékgyűjtés (10. szakasz) ott még nagyobb súlyú.

8.2 NIS2 és a magyar kiberbiztonsági törvény

A NIS2 (EU 2022/2555) alapjai és a magyar átültetés (2024. évi LXIX. törvény, felügyelet az SZTFH, incidensbejelentés a Nemzeti Kibervédelmi Intézet felé) az Adatbiztonság és adatvédelem kézikönyvben szerepelnek. Megfelelési szempontból néhány friss tény jön hozzá. A törvény szerinti első kiberbiztonsági audit határideje a 2025-ös módosítás után 2026. június 30. volt, ez lejárt, azóta az audit általában kétévente esedékes. A lefolytatás rendjét és a legmagasabb díjat SZTFH rendelet (1/2025.) szabályozza, a végrehajtási rendeletek 2026-ban is módosultak. Hatályos szövegük a Nemzeti Jogszabálytárban ellenőrizendő.

Egy kis fejlesztő cég jellemzően nem maga érintett szervezet, de beszállítója lehet érintetteknek, és a NIS2 ellátási lánc követelménye miatt az ügyfél szerződésben fogja kérni a megfelelő kontrollokat. A 21. cikk (2) bekezdésének tíz intézkedése jól leképezhető a 27001-re.

A 20. cikk a vezetés felelősségét és képzését írja elő (5. klauzula, 7.2). Bejelentési ütemét a 23. cikk adja (korai figyelmeztetés 24 órán belül, bejelentés 72 órán belül, záró jelentés egy hónapon belül), ez az incidensnapló döntési mezőiben jelenik meg. Magyar szabályozás a biztonsági osztályhoz kötött saját védelmi intézkedés katalógust is használ. Egy 27001 tanúsítvány ezért erős alap, de nem helyettesíti automatikusan a magyar kiberbiztonsági auditot, a két követelményrendszer közti eltérést esetenként kell felmérni.

8.3 Cyber Resilience Act (EU 2024/2847)

A CRA a digitális elemeket tartalmazó termékek gyártóira vonatkozik, tehát termékszintű szabály, ellentétben a 27001-gyel. Digitális elemet tartalmazó termék a forgalomba hozott szoftver is (letölthető alkalmazás, asztali app, mobilapp, kereskedelmileg terjesztett könyvtár vagy npm csomag, telepíthető MCP szerver). A tisztán távoli szolgáltatásként nyújtott SaaS általában nem tartozik ide, kivéve ha egy termék távoli adatfeldolgozó része. Nem kereskedelmi nyílt forráskód kívül esik, a nyílt forrású szoftvert gondozó szervezetekre (open source steward) enyhébb szabály vonatkozik. Hatály kérdésében jogász dönt. A fejlesztőcsapat feladata, hogy a projekt elején feltegye a kérdést, és a választ a projekt README-jében rögzítse.

Bejelentési ütem. Korai figyelmeztetés 24 órán belül, bejelentés 72 órán belül, záró jelentés kihasznált sebezhetőségnél legkésőbb 14 nappal a javítás elérhetővé válása után, súlyos incidensnél egy hónapon belül. A részletes szabály a rendelet 14. cikkében és az ENISA útmutatóiban ellenőrizendő.

Gyártói kötelezettségek fejlesztői fordításban.

• Biztonság a tervezésben (I. melléklet I. rész). Ismert kihasználható sebezhetőség nélküli kiadás, biztonságos alapkonfiguráció, hozzáférés védelem, bizalmasság és sértetlenség, adattakarékosság, a támadási felület csökkentése, naplózás, biztonságos frissítés, az adatok törölhetősége. A 8.25-8.29 kontrollok bizonyítékai jól használhatók.
• Sebezhetőségkezelés (I. melléklet II. rész). SBOM legalább a közvetlen függőségekre, gépileg olvasható formában (CycloneDX vagy SPDX), sebezhetőségek késedelem nélküli javítása, rendszeres tesztelés, a javított sebezhetőségek nyilvános közzététele, koordinált sebezhetőség közzétételi szabály és kapcsolattartó, biztonsági frissítések biztonságos és díjmentes terjesztése.
• Támogatási időszak. A termék várható használati idejéhez igazítva, főszabályként legalább öt év, ameddig biztonsági frissítést kell adni.
• Műszaki dokumentáció és megfelelőségértékelés. Alapkategóriában a gyártó belső ellenőrzése, a fontos és kritikus kategóriákban harmonizált szabvány vagy harmadik fél bevonása. EU megfelelőségi nyilatkozat, CE jelölés, a dokumentáció tíz évig megőrzendő.

Leképezés a 27001-re. 8.8 (sebezhetőség), 5.24-5.26 (incidens és bejelentés), 8.25-8.29 (biztonságos fejlesztés), 5.21 (SBOM, ellátási lánc), 5.37 (dokumentált eljárások), 5.31 (jogszabályi regiszter). Egy működő ISMS a CRA gyártói folyamatainak nagy részét lefedi, de a termékszintű kimeneteket (műszaki dokumentáció, megfelelőségi nyilatkozat, támogatási időszak közlése) külön kell előállítani.

8.4 OWASP ASVS és SAMM mint bizonyíték

Az ASVS 5.0 (részletesen a Kiberbiztonság kézikönyvben) a 8.26 és 8.29 bizonyítéka. A projekt kijelöli a szintet (L1 minden webalkalmazásra, L2 személyes vagy üzleti adatnál), a követelményeket a releváns fejezetekből a követelmény nyomonkövetési mátrixba veszi, és mindegyikhez tesztet vagy review pontot rendel. Az auditor szemében egy kitöltött ASVS ellenőrzőlista, követelményenként igazolással, erős bizonyíték arra, hogy a biztonsági követelmény nem csak szándék.

Érettségi oldalról az OWASP SAMM 2 a fejlesztési szervezet érettségét méri öt üzleti funkcióban (irányítás, tervezés, megvalósítás, verifikáció, üzemeltetés), funkciónként három gyakorlattal és három érettségi szinttel. A 8.25 bizonyítéka lehet egy évente elvégzett SAMM önértékelés célszintekkel és javítási tervvel. Kis csapatnál a teljes kérdőív helyett a releváns gyakorlatok (fenyegetésértékelés, biztonsági követelmények, biztonságos build, biztonságos deploy, hibakezelés, incidenskezelés) értékelése is elég.

8.5 NIST SSDF (SP 800-218)

A Secure Software Development Framework 1.1-es változata (2022) négy gyakorlatcsoportot ír le. Az 1.2-es változat (SP 800-218 Rev. 1) tervezete 2025 decemberében jelent meg, a véglegesítése a 2026 októberi állapot szerint nem ismert, ellenőrizendő. AI modellek fejlesztésére az SP 800-218A egészíti ki a keretet. Amerikai közbeszerzési vagy nagyvállalati ügyfél gyakran kéri, és a 27001 kontrollokkal jól megfeleltethető.

9. Auditkész fejlesztési folyamat

A mindennapi fejlesztés jól beállítva magától termel auditbizonyítékot. Cél egy olyan munkarend, amelyben a bizonyíték a munka mellékterméke, és nem az audit előtti héten készül.

9.1 Nyomon követhetőség a követelménytől a deployig

Az auditor egy változást vagy egy követelményt választ ki, és végig akarja követni. A lánc szemei és a köztük lévő kapcsolat így néz ki.

Követelmény (REQ-012, issue #48)
  → Branch (feat/48-tenant-export)
  → PR #57 ("Closes #48", PR sablon kitöltve: kockázat, rollback, biztonsági hatás)
  → Review jóváhagyás (név, időpont)
  → CI futás (teszt, lint, gitleaks, semgrep, advisor kapu, SBOM) zöld
  → Merge commit (SHA)
  → Migráció (supabase/migrations/20261014093000_tenant_export.sql)
  → Release (v1.8.0, generált release notes)
  → Deploy (Vercel deployment ID, production)
  → Élesítés utáni ellenőrzés (smoke teszt, advisor futás)

A követelmény nyomonkövetési mátrix tartja egyben.

9.2 Változáskezelés (8.32)

Változástípusok. Standard változás (előre jóváhagyott, alacsony kockázatú, például függőség patch frissítése zöld CI-jal), normál változás (PR, review, CI, release) és sürgősségi változás (éles hiba vagy aktívan kihasznált sebezhetőség). Sürgősségi változásnál a review utólagos is lehet, de egy munkanapon belül meg kell történnie, és a változásnapló rögzíti az indokot.

PR sablon minimum. Mit változtat és miért (issue hivatkozás), kockázati szint, érint-e auth, jogosultság, személyes adat, titok, LLM eszköz területet, hogyan tesztelték, rollback terv, migráció visszafordíthatósága, frissítendő compliance dokumentumok listája.

Egyszemélyes csapat. A feladatok szétválasztása (5.3) egy embernél nem valósítható meg teljesen, ezt az auditor is tudja. Kompenzáló kontroll kell, és ezt a SoA-ban le kell írni. Kötelező CI kapuk, amelyeket az admin sem kerülhet meg, kötött önátnézési checklist a PR-ben, negyedéves utólagos review külső személlyel egy mintán, és a magas kockázatú változásokra (auth, fizetés, RLS) eseti külső review. Az AI alapú review dokumentálható kiegészítő ellenőrzésként, de nem helyettesíti a felelős ember jóváhagyását, és az auditor sem fogadja el független jóváhagyásként.

Migrációk. A Supabase migráció a változás része, ugyanabban a PR-ben, verziószámmal, és az éles alkalmazás nyoma a supabase_migrations.schema_migrations táblában található. Kézi séma módosítás az éles konzolon tilos, vagy ha mégis megtörtént, utólagos migrációval és naplóbejegyzéssel kell rendezni (lásd az Adat és adatbázisok kézikönyv migrációs szabályait).

9.3 Környezetek szétválasztása (8.31, 8.33)

A preview soha nem mutat éles adatbázisra, a service role és az éles LLM kulcs csak a Production szkópban él. Éles adat másolása fejlesztésre csak maszkolva és dokumentált jóváhagyással történhet.

9.4 Hozzáférés felülvizsgálat (5.18, 8.2)

Negyedévente, és minden kilépésnél azonnal. A hozzáférés felülvizsgálati napló egy bejegyzése rendszerenként tartalmazza a felhasználót, a szerepet, a szükségességet (igen vagy nem), a teendőt és a végrehajtás dátumát.

Ellenőrzendő rendszerek egy tipikus stacknél. GitHub szervezet és repók (tagok, külső közreműködők, deploy kulcsok, GitHub App telepítések, finomhangolt tokenek), Supabase szervezet és projektek, Vercel csapat, Anthropic és OpenAI konzol (tagok és API kulcsok), Stripe, email küldő szolgáltató, DNS és domain regisztrátor, jelszókezelő megosztott tárolói, monitoring és log tár, valamint az AI kódoló eszközök tokenjei és MCP szerver hozzáférései.

# GitHub. Tagok, külső közreműködők, repó jogosultságok (olvasás, a kimenet dátumozva mentve)
gh api orgs/ORG/members --paginate --jq '.[].login'
gh api orgs/ORG/outside_collaborators --paginate --jq '.[].login'
gh api repos/ORG/REPO/collaborators --paginate --jq '.[] | [.login, .role_name] | @tsv'
gh api repos/ORG/REPO/keys --jq '.[] | [.title, .read_only, .created_at] | @tsv'

A Supabase, a Vercel és az LLM konzolok tagjairól dátumozott export vagy képernyőkép készül. Ahol API van rá, ott szkript, ahol nincs, ott kézi lista a felülvizsgáló nevével.

9.5 Naplómegőrzés (8.15)

A naplózási szabály négy kérdésre felel. Mit naplózunk (biztonsági események, admin műveletek, adatexport, jogosultságváltozás, LLM eszközhívások), hol (alkalmazás audit tábla, log drain célpont), mennyi ideig (például biztonsági napló 12 hónap, alkalmazásnapló 30 nap, a szerződésből és a jogszabályból levezetve), ki fér hozzá. A platformok beépített megőrzése csomagtól függően rövid. Hosszabb megőrzéshez log drain kell EU régiós tárba, a beszállítói nyilvántartásban rögzítve. A napló is személyes adat, ezért redakció és megőrzési idő ott is kötelező (a technikai oldalt a Kiberbiztonság kézikönyv naplózási szakasza tárgyalja).

9.6 Mentési próbák jegyzőkönyve (8.13, 5.30)

Negyedévente egy visszaállítási próba külön Supabase projektbe, a mentési és helyreállítási tervben rögzítve.

A Supabase adatbázis mentése a Storage objektumait nem tartalmazza, csak a metaadatukat. Ezt a projekt elején kell kezelni, nem a próbán felfedezni. A visszaállításhoz szükséges titkok (környezeti változók, webhook titkok) leltára is a mentési terv része.

9.7 Sebezhetőségkezelés SLA-val (8.8)

A CVSS mellett a kontextus dönt. Egy fejlesztési függőség kritikus sebezhetősége, amely nem kerül a buildbe, alacsonyabb prioritást kaphat, de ezt a sebezhetőségkezelési napló kivétel szakaszában indokolni kell, felelőssel és felülvizsgálati dátummal. Az auditor a nyitott tételek korát nézi az SLA-hoz képest, és a kivételek indoklását.

9.8 Beszállítói nyilvántartás (5.19-5.23)

A beszállítói nyilvántartás minden olyan külső szolgáltatást tartalmaz, amely adatot kap, kódot futtat vagy a szolgáltatás működéséhez kell. Az alábbi sorok minták, a tényleges tanúsítványokat, a DPA változatát és az adatkezelési feltételeket a beszállító trust portálján kell ellenőrizni, dátummal.

LLM szolgáltatónál külön rögzítendő, hogy az API-n küldött adatot tanításra használja-e (kereskedelmi API-nál jellemzően nem), mennyi ideig őrzi, és van-e zero data retention vagy EU adattárolási lehetőség. Ezek a feltételek változnak, ezért éves felülvizsgálat és változásfigyelés kell. A fejlesztők által használt AI kódoló eszközök is beszállítók, mert forráskódot és esetenként ügyféladatot látnak.

9.9 Titkosítási politika (8.24)

A titkosítási szabály egy oldal. Átvitel közben TLS 1.2 vagy újabb, HSTS, adatbázis kapcsolat SSL kényszerítéssel. Tárolt adatnál a szolgáltatói titkosítás (beszállítói hivatkozással), érzékeny mezőnél alkalmazásszintű titkosítás döntése és módja. A jelszókezelést a Supabase Auth végzi, saját jelszótárolás nincs. Titkok csak környezeti változóban vagy Supabase Vaultban, soha a repóban. Kulcsleltár névvel, hellyel, tulajdonossal, rotációs gyakorisággal és utolsó rotációval. Tiltott algoritmusok (MD5 és SHA-1 biztonsági célra, ECB mód, saját kriptográfia). A részleteket az Adatbiztonság és adatvédelem kézikönyv kriptográfiai és titokkezelési szakasza adja.

9.10 Incidensnapló és tanulságok (5.24-5.28)

Az incidensnapló nemcsak a nagy incidenseket rögzíti, hanem a biztonsági eseményeket és a majdnem bekövetkezett hibákat is. Egy év üres incidensnapló az auditor szemében nem a biztonság jele, hanem azé, hogy nincs észlelés vagy nincs rögzítés.

9.11 Release és release notes

Minden kiadáshoz a release checklist kitöltött példánya (vagy a release PR-ben kipipált lista) és generált release notes tartozik. A gh release create v1.8.0 --generate-notes a PR címekből és szerzőkből állítja össze, ez egyben a változások listája a 8.32-höz. Mellé csatolható az SBOM és a teszt összefoglaló.

10. Automatizált bizonyítékgyűjtés

10.1 Elv. Bizonyíték kódként

Ami géppel lekérdezhető, azt havonta és minden release-nél gép gyűjti, dátumozva, és olyan helyre menti, ahol az audit ciklusig (legalább három évig) megmarad. A GitHub Actions naplók és artefaktumok megőrzése korlátozott, ezért a CI kimenete nem lehet az egyetlen bizonyítékforrás. Gyűjtött csomag kerülhet egy külön, írásvédett evidence repóba, EU régiós objektumtárba verziózással, vagy a compliance eszköz tárolójába. Minden fájlhoz SHA-256 hash készül, a hash lista is a csomag része.

10.2 Minta munkafolyamat

Havonta és release-kor futó GitHub Actions munkafolyamat vázlata. Az action hivatkozásokat a Kiberbiztonság kézikönyv ellátási lánc szabályai szerint SHA-ra pineljük, a <SHA> helyére a tényleges commit hash kerül.

name: compliance-evidence
on:
  schedule:
    - cron: "0 6 1 * *"        # minden hónap 1-jén 06:00 UTC
  release:
    types: [published]
  workflow_dispatch:

permissions:
  contents: read
  security-events: read
  pull-requests: read

jobs:
  collect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<SHA>   # v4
        with: { fetch-depth: 0 }
      - uses: actions/setup-node@<SHA> # v4
        with: { node-version: 22 }
      - run: npm ci
      - name: Gyűjtés
        env:
          GH_TOKEN: ${{ secrets.EVIDENCE_READ_TOKEN }}   # csak olvasási jogú finomhangolt token
        run: |
          OUT="evidence/$(date -u +%Y-%m)"
          mkdir -p "$OUT"
          R="${GITHUB_REPOSITORY}"
          gh api "repos/$R/rulesets" > "$OUT/rulesets.json"
          gh api "repos/$R/dependabot/alerts" --paginate > "$OUT/dependabot.json"
          gh pr list --state merged --limit 500 \
            --json number,title,author,mergedAt,mergedBy,reviews > "$OUT/merged-prs.json"
          gh run list --branch main --limit 200 \
            --json databaseId,name,conclusion,createdAt,headSha > "$OUT/ci-runs.json"
          npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file "$OUT/sbom.cdx.json"
          npm audit --json > "$OUT/npm-audit.json" || true
          (cd "$OUT" && sha256sum *.json > SHA256SUMS)
      - uses: actions/upload-artifact@<SHA> # v4
        with:
          name: evidence-${{ github.run_id }}
          path: evidence/
          retention-days: 90
      # Hosszú távú megőrzés: külön lépés az írásvédett evidence tárba (EU régió, verziózás)

A gitleaks és a semgrep a PR munkafolyamatban fut kapuként, a havi gyűjtés csak az összesítő riportot menti. A Supabase advisors futtatása vagy a Supabase MCP-n keresztül történik (AI asszisztált munkamenetben, olvasási joggal), vagy a CI-ban a Management API-n át, ha a projekt ezt beállította. Kimenete ugyanebbe a csomagba kerül.

10.3 Compliance automatizáló eszközök

A Vanta, a Drata és a Secureframe jellegű platformok integrációkon keresztül folyamatosan gyűjtenek bizonyítékot (GitHub, felhőkonzolok, identitásszolgáltató, MDM, HR rendszer), automatikus kontrollteszteket futtatnak (például minden fiókon van-e MFA, védett-e a fő ág), szabályzatsablonokat, munkatársi elfogadást és képzést, beszállítói kérdőíveket és nyilvános trust centert adnak, és összekötnek auditorokkal. Költségük kis cégnek is jellemzően évi több ezer dollártól indul, az aktuális ár ajánlat alapján derül ki.

Amit nem végeznek el.

• A hatókör, a kockázatértékelés és a kockázatelfogadás döntése emberi feladat marad.
• A szabályzatsablon nem lesz igaz attól, hogy elfogadták. Ha a sablon olyan folyamatot ír le, ami nincs, az a leggyorsabb út egy megállapításhoz.
• Az alkalmazásszintű kontrollokat (helyes-e az RLS policy, valóban izolált-e a tenant, mit tehet az ügynök egy eszközzel) az integráció nem látja. Egy zöld pipa azt igazolja, hogy be van kapcsolva valami, azt nem, hogy jól működik.
• A Supabase, az LLM szolgáltatók és az MCP szerverek integrációja eszközönként eltér, ezt beszerzés előtt ellenőrizni kell.
• A belső audit függetlenségét, a vezetőségi átvizsgálás tartalmát és a helyesbítő intézkedések minőségét nem helyettesítik.

Nyílt forrású és olcsó alternatívák. A CISO Assistant (intuitem) nyílt forrású GRC eszköz sok keretrendszer katalógussal és leképezéssel, az Eramba közösségi kiadása kockázat és kontrollkezelésre való, a Comp AI és a Probo nyílt forrású, kifejezetten 27001 és SOC 2 felkészítésre épülő projektek. Az aktuális állapotuk és licencük használat előtt ellenőrizendő. Egy 1-5 fős csapatnak gyakran elég a gitben vezetett compliance mappa, a havi bizonyítékgyűjtő munkafolyamat és egy táblázat a szervezeti SoA-hoz. Fizetős platform akkor éri meg, ha több keretrendszert (27001 és SOC 2) kell párhuzamosan fenntartani, vagy sok ügyfél küld biztonsági kérdőívet.

11. Tipikus audit megállapítások kis szoftvercégeknél és vibecoding projekteknél

12. Egy kis cég (1-5 fő) útja a 27001 tanúsításig

12.1 Ütemezés

Realisztikusan hat-kilenc hónap az elhatározástól a tanúsítványig, érett gyakorlatú csapatnál négy-öt hónap. A legnagyobb időtényező a működés bizonyítása. Stage 2 előtt legyen legalább két-három hónapnyi record, egy elvégzett belső audit és egy vezetőségi átvizsgálás.

12.2 Költségnagyság

Nagyságrendi becslés 2026-ra, árajánlat nélkül nem tervezhető. Nagyban függ a tanúsítótól, a hatókörtől, a kiinduló érettségtől és attól, mennyit visz a csapat saját erőből.

12.3 Minimum dokumentáció és elhelyezése

A 2.2 pont kötelező listáját egészítik ki azok a dokumentumok, amelyeket az A melléklet kontrolljai gyakorlatilag megkövetelnek. Szervezeti szinten (a közös ISMS repóban vagy mappában) a hatókör, a politika, a kockázatkezelési módszertan, a szervezeti SoA, a célok, a kompetencia és képzési nyilvántartás, a belső audit program és jelentések, a vezetőségi átvizsgálás jegyzőkönyvei, a nem megfelelőség napló, a jogszabályi regiszter, a leltár és a fő szabályzatok (hozzáférés, elfogadható használat, beszállító, incidens, folytonosság, kriptográfia, biztonságos fejlesztés, mentés, naplózás, osztályozás, távmunka). Projektszinten a compliance mappa adja a bizonyítékot és a projektre jellemző megvalósítást (dokumentumonként a következő, gyakorlati összefoglalóban).

Kis cégnél a szabályzatok összevonhatók. Egy 15-25 oldalas, valós működést leíró ISMS kézikönyv jobb, mint negyven sablonból átvett dokumentum, amelyet senki nem olvasott.

A gyakorlatban

Az alábbi szabályok minden olyan fejlesztési munkára érvényesek, ahol a projekt ügyfélnek készül, személyes adatot kezel, éles környezetbe kerül, vagy az ügyfél auditot említ, akár ember írja a kódot, akár egy kódgeneráló modell. Eldobható prototípusnál nem szükségesek.

Új projektnél a compliance dokumentumkészlet

Új projekt indításakor a csapat a repóban létrehoz egy compliance mappát (például docs/compliance/) a szervezet sablonjaiból, és kitölti, amit a projekt ismeretében már ki lehet tölteni. Ami még ismeretlen, TODO (felelős, határidő) jelölést kap, és a hiánylistára kerül.

Minden változtatásnál

A kódváltozással ugyanabban a PR-ben frissülnek az érintett compliance dokumentumok, és a PR leírása felsorolja, melyik miért változott.

Hitelességi szabályok. Ezek emberre és AI asszisztensre egyaránt vonatkoznak, és különösen akkor számítanak, amikor a dokumentumokat egy kódgeneráló modell tölti ki.

• Bizonyíték csak a valós működésből származhat. Elvégzettként nem kerül be visszaállítási próba, felülvizsgálat vagy képzés, amely nem történt meg, és visszadátumozás sincs.
• Jóváhagyást, elfogadást, aláírást csak az érintett ember adhat. A mező Jóváhagyásra vár: <szerep> marad, amíg az illető maga ki nem tölti vagy PR-ben jóvá nem hagyja.
• Ahol nincs bizonyíték, ott a dokumentum ezt kimondja (Bizonyíték: nincs), és a tétel a hiánylistára kerül.
• A dokumentumok nem állítják, hogy a projekt ISO tanúsított vagy megfelelő. A megfogalmazás arról szól, hogy egy adott kontrollhoz van-e bizonyíték, a tanúsításról pedig az auditor dönt.
• Titok, kulcs és személyes adat compliance dokumentumba sem kerül.

Deploy előtti megfelelési kapu

Éles deploy vagy release előtt a csapat végigmegy az alábbi kapun, és az eredményt a release checklist példányában vagy a release PR-ben rögzíti. Blokkoló tételnél élesítés csak a felelős kifejezett, rögzített kockázatelfogadásával történhet.

Audit szimuláció

Rendszeresen, és mindig a tanúsítási audit előtt, egy belső audit szimuláció mutatja meg, mennyire auditkész egy projekt. Végezheti a csapat egy tagja, egy külső kolléga, vagy olvasási jogú AI asszisztens. A szimuláció csak olvas, éles rendszert nem módosít, semmit nem kapcsol be vagy ki, és a végén jelentést ad. Szimuláció, nem audit, a minősítései javaslatok.

1. Hatókör és mérce. A vizsgáló rögzíti, mely szabványok szerint vizsgál. Alapértelmezés a 27001:2022 A mellékletének fejlesztést érintő kontrolljai. Kiegészül a 27701 és GDPR szemponttal, ha személyes adat van, a 42001 szemponttal, ha LLM vagy ügynök van, a CRA szemponttal, ha a szoftver terjesztett termék, és a NIS2 leképezéssel, ha az ügyfél érintett szervezet. Ez a jelentés elejére kerül.

2. Leltár. A vizsgálat kiterjed a compliance mappára, a README-re, a CI munkafolyamatokra (.github/workflows/), a supabase/ mappára (migrációk, config.toml, seed), a package.json-ra és a lockfile-ra, a CODEOWNERS-re, a PR sablonra, és az AI kódoló eszközök projektszintű utasításfájljára, ha van ilyen.

3. Bizonyítékkeresés kontrollonként. Minden vizsgált kontrollhoz a 3. szakasz táblázata szerinti bizonyítékot keres a vizsgáló, olvasó parancsokkal.

gh api repos/ORG/REPO/rulesets                       # 8.4, 8.32
gh api repos/ORG/REPO/branches/main/protection       # 8.32
gh pr list --state merged --limit 50 --json number,reviews,mergedBy,mergedAt
gh api repos/ORG/REPO/dependabot/alerts --paginate --jq '[.[] | select(.state=="open")] | length'
gitleaks git --report-format json --report-path /tmp/gl.json   # vagy a CI utolsó riportja
semgrep scan --config p/default --json --output /tmp/sg.json
npm audit --json
supabase migration list
git log --since="90 days ago" --format='%h %an %ad %s' -- docs/compliance/

Supabase projektnél a Supabase MCP get_advisors és list_tables hívásai vagy a CLI adnak olvasási hozzáférést az RLS állapothoz és az advisor figyelmeztetésekhez. Az API nélküli konzolbeállítások kérdésként kerülnek a projektgazda elé (például hogy be van-e kapcsolva a PITR az éles projekten), a jelentés pedig a választ forrásként jelöli (a projektgazda közlése szerint).

4. Mintavétel. Öt véletlenszerűen kiválasztott, az utolsó negyedévben összevont PR mindegyikét végigköveti a vizsgáló. Van-e issue vagy követelmény, van-e emberi jóváhagyás, zöld volt-e a CI, van-e hozzá release és deploy, frissültek-e az érintett compliance dokumentumok. Egy kilépett vagy inaktív közreműködőnél azt is ellenőrzi, megszűnt-e a hozzáférése.

5. Minősítés. Kontrollonként négy kategória. Megfelel (van működési bizonyíték, aktuális), Részben (van szabály vagy beállítás, de hiányos a nyom, vagy elavult), Hiányzik (nincs se szabály, se nyom), Nem alkalmazható (indokkal). A hiányok javasolt besorolást kapnak (major jellegű, minor jellegű, észrevétel) a 2.5 pont szerint, kifejezetten javaslatként.

6. Jelentés. A jelentés dátumozott dokumentumként a compliance mappába kerül, például audit-szimulacio-ÉÉÉÉ-HH-NN.md néven.

# Audit szimuláció. <projekt>, <dátum>

Mérce: ISO/IEC 27001:2022 A melléklet (fejlesztést érintő kontrollok) + <további>
Módszer: dokumentum, repó, CI és Supabase advisor átnézés, 5 PR mintavétel
Korlát: szimuláció, nem tanúsítási audit. Konzolbeállítások egy része a projektgazda közlésén alapul.

## Összkép
Megfelel: 21 · Részben: 9 · Hiányzik: 6 · Nem alkalmazható: 3

## Hiánylista kockázat szerint
| # | Kontroll | Megállapítás | Bizonyíték, ami hiányzik | Javasolt besorolás | Javítás | Ráfordítás |
|---|----------|--------------|--------------------------|--------------------|---------|------------|
| 1 | 8.13 | Visszaállítási próba nem volt, Storage nincs mentve | Próbajegyzőkönyv | Major jellegű | Próba külön projektbe, Storage szinkron | 0,5 nap |
| 2 | 5.18 | Volt alvállalkozó írási joggal a repón | Felülvizsgálati jegyzőkönyv | Minor jellegű | Visszavonás, kilépési checklist | 1 óra |

## Mintavétel
| PR | Követelmény | Jóváhagyás | CI | Release | Compliance frissítés |
|----|-------------|------------|----|---------|----------------------|

## Kontrollonkénti részletek
<kontroll, minősítés, talált bizonyíték útvonallal vagy paranccsal, hiány>

## Következő lépések
<a három legnagyobb kockázatú hiány javítása, felelős, határidő javaslat>

7. Utánkövetés. A hiánylista tételei a felelős jóváhagyásával issue-ként vagy a kockázatregiszterbe kerülnek, és a következő szimuláció elsőként ezek lezárását ellenőrzi.

Amit a csapat mindig jelez

• Ha az ügyfél ISO megfelelő szoftvert kér, ígéret előtt tisztázni kell a 0. szakasz szerinti különbséget (szervezeti ISMS és termék).
• Ha a szoftver terjesztett termék, a CRA hatály kérdése a projekt elején felmerül, mert a jelentéskötelezettség 2026. szeptember 11. óta él.
• Ha AI funkció kerül a projektbe, a 42001 és az AI Act szempontjából rendszerkártya és hatásvizsgálat kell, és a vázlatuk már a tervezéskor elkészül.
• Ha egy kért gyorsítás (közvetlen push, éles adat a fejlesztéshez, review kihagyása) auditmegállapítást okozna, ez a döntéshozó elé kerül, a dokumentált kivétellel vagy a szabályos úttal együtt.
• A szabványok verzióját és a jogszabályi határidőket audit előtt friss forrásból ellenőrizzük. Jogi kérdésben a jogász, tanúsítási kérdésben a tanúsító szervezet az illetékes.

Állapot 2026 októberében. A szöveg szakmai összefoglaló, nem jogi tanácsadás, a szabványok és jogszabályok aktuális szövegét a kiadótól érdemes ellenőrizni.

Források

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection. Information security management systems. Requirements, valamint az Amd 1:2024 módosítás.
• ISO/IEC 27002:2022, Information security controls.
• ISO/IEC 27005:2022, Guidance on managing information security risks.
• ISO 31000:2018, Risk management. Guidelines.
• ISO/IEC 27701:2025, Privacy information management systems.
• ISO/IEC 27017, felhőszolgáltatások információbiztonsági kontrolljai, 2. kiadás, 2026.
• ISO/IEC 27018, PII védelme nyilvános felhőben, 3. kiadás, 2025.
• ISO/IEC 27034 sorozat, Application security.
• ISO/IEC 27006-1:2024, a tanúsító szervezetekre vonatkozó követelmények.
• ISO/IEC 42001:2023, Artificial intelligence. Management system.
• ISO/IEC 42005:2025, AI system impact assessment.
• ISO/IEC 25010:2023, Product quality model.
• ISO/IEC/IEEE 29119 sorozat, Software testing, és ISO/IEC TR 29119-11.
• ISO/IEC/IEEE 12207:2017, Software life cycle processes.
• ISO 9001:2026, Quality management systems. Requirements.
• ISO 22301:2019 és Amd 1:2024, Business continuity management systems.
• ISO/IEC 15408 (Common Criteria).
• AICPA, Trust Services Criteria (2017, a fókuszpontok 2022-es frissítésével), és a TSC és ISO/IEC 27001 leképezés.
• Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR).
• Az Európai Parlament és a Tanács (EU) 2022/2555 irányelve (NIS2).
• 2024. évi LXIX. törvény Magyarország kiberbiztonságáról, és az SZTFH 1/2025. rendelete.
• Az Európai Parlament és a Tanács (EU) 2024/2847 rendelete (Cyber Resilience Act).
• Az Európai Parlament és a Tanács (EU) 2024/1689 rendelete (AI Act).
• OWASP Application Security Verification Standard 5.0, 2025.
• OWASP Software Assurance Maturity Model (SAMM) 2.
• NIST SP 800-218, Secure Software Development Framework 1.1, 2022, az SP 800-218 Rev. 1 tervezete (2025) és az SP 800-218A.
• NIST SP 800-63B-4, Digital Identity Guidelines.
• CISA Known Exploited Vulnerabilities katalógus.
• IAF CertSearch (iafcertsearch.org) és a Nemzeti Akkreditáló Hatóság nyilvántartása.