DORA ICT-tredjepartserklæring for AgentBase
| Felt | Værdi |
|---|---|
| Dokumenttitel | ICT-tredjepartserklæring for AgentBase under DORA |
| Version | 1.0 |
| Senest opdateret | 2026-05-18 |
| Dokumentejer | syv.ai (kontakt: mads@syv.ai) |
| Reviewfrekvens | Mindst én gang årligt og ved væsentlige ændringer i platformen, datahåndtering eller risikobillede |
| Tilhørende dokumenter | Systembeskrivelse, Dataflow, Databehandleraftale, Underdatabehandlere, NIS2-erklæring |
Denne side er udarbejdet til finansielle entiteter, der er omfattet af DORA (Europa-Parlamentets og Rådets forordning (EU) 2022/2554 om digital operationel modstandskraft i den finansielle sektor). Dokumentet beskriver, hvordan AgentBase som ICT-tredjepartsudbyder understøtter kundens forpligtelser, særligt vedrørende styring af ICT-tredjepartsrisici (art. 28–30), hændelsesrapportering (art. 17–23) og operationel modstandskraft.
DORA finder fuld anvendelse fra 17. januar 2025. Henvisninger nedenfor er til forordningens artikler.
1. Indledning og parternes roller under DORA
| Rolle under DORA | Part |
|---|---|
| Finansiel entitet (kunden) | Kunden, jf. DORA art. 2, fx kreditinstitut, betalingsinstitut, e-pengeinstitut, investeringsselskab, forsikrings- eller genforsikringsselskab |
| ICT-tredjepartsudbyder | syv.ai ApS som udbyder af AgentBase, jf. DORA art. 3, nr. 19 |
1.1 AgentBase's status under DORA
syv.ai ApS er en ICT-tredjepartsudbyder af et software-as-a-service-produkt (AgentBase). AgentBase er ikke udpeget som kritisk ICT-tredjepartsudbyder (CTPP) efter DORA art. 31 og opererer ikke under direkte tilsyn af European Supervisory Authorities (ESA'er) på den måde, der gælder for CTPP'er. syv.ai er ikke en finansiel entitet.
Det er kundens den finansielle entitets ansvar at gennemføre den dokumentation, klassifikation og kontraktindgåelse, som DORA pålægger. Denne side leverer den leverandørside-input, der er nødvendig for at kunden kan opfylde sine forpligtelser.
1.2 Hvad denne erklæring ikke dækker
- Kundens samlede DORA-compliance: Denne side dokumenterer kun AgentBase som leverance. Kundens ICT-risikohåndteringsramme (art. 5–15), hændelsesrapportering til myndighederne (art. 19) og testprogram (art. 24–27) er kundens ansvar.
- Kundens egne integrationer: Hvis kunden konfigurerer agents, der kalder kundens egne eksterne systemer (via
http_request-,email-,cvr_lookup- ellersql-noder), er behandlingen ikke en del af AgentBase's egen ICT-tredjepartsleverance, jf. Dataflow §5.
2. Klassifikation af AgentBase som understøtter af kritisk/vigtig funktion
DORA stiller forskellige krav til ICT-kontrakter afhængigt af, om kontrakten understøtter kritiske eller vigtige funktioner hos kunden (jf. art. 3, nr. 22). Klassifikationen foretages af kunden på baggrund af kundens egen risikovurdering ikke af syv.ai.
For at understøtte kundens vurdering kan følgende lægges til grund:
| Spørgsmål | Indikation |
|---|---|
| Anvendes AgentBase til at automatisere processer, der direkte påvirker kundens kerneydelser (kreditbehandling, betalingsbehandling, KYC/AML, regulatorisk rapportering)? | Hvis ja → typisk kritisk eller vigtig funktion |
| Anvendes AgentBase til intern administration, vidensøgning eller andre opgaver, hvor et udfald ikke har umiddelbar effekt på kunder eller compliance? | Typisk ikke kritisk/vigtig funktion |
| Vil kundens kunder eller modparter opleve væsentlig forringelse, hvis AgentBase er utilgængelig i 24 timer? | Hvis ja → typisk kritisk eller vigtig funktion |
Hvis AgentBase understøtter en kritisk eller vigtig funktion, gælder de supplerende krav i art. 30(3). Disse er beskrevet i §5 nedenfor.
3. ICT-risikohåndteringsramme og operationel modstandskraft
Følgende elementer fra DORA art. 5–15 understøttes af AgentBase:
| DORA-emne | Hvor det leveres af AgentBase |
|---|---|
| Identifikation og klassifikation af ICT-aktiver (art. 8) | Systembeskrivelsen §2 leverer den ICT-aktivbeskrivelse, kunden kan indsætte i sit eget aktivregister |
| Beskyttelse og forebyggelse (art. 9) | Kryptografi, adgangskontrol og udviklingssikkerhed beskrevet i Systembeskrivelsen §6.3 og Dataflow §6 |
| Detektion (art. 10) | Struktureret applikationslogning og auditspor pr. brugerhandling, eksporterbart til kundens eget SIEM via LOG_JSON=true, jf. Dataflow §7 |
| Respons og gendannelse (art. 11) | Backups og gendannelsesmål beskrevet i NIS2-erklæringen §4 |
| Backup-politikker og gendannelsesmetoder (art. 12) | Daglige automatiske backups, krypteret, opbevaret geografisk adskilt inden for EU/EØS |
| Læring og udvikling (art. 13) | Versioneret kode, releaseproces og changelog. Lærdomme fra hændelser dokumenteres internt |
| Kommunikation under hændelser (art. 14) | Hændelsesnotifikation til kunden uden unødigt ophold, jf. NIS2-erklæringen §3 og Databehandleraftalen Bestemmelse 10 |
3.1 Kontroller under udvikling
For at imødekomme finansielle kunders øgede dokumentations- og kontrolkrav arbejder syv.ai aktivt på følgende kontroller. Status kan indgå i kundens egen vurdering af leverandørens modenhed under art. 28(4):
| Kontrol | Status | Forventet effekt under DORA |
|---|---|---|
| ISO/IEC 27001-certificering af syv.ai's ISMS | Under implementering | Uafhængig tredjepartsevidens for art. 30(2)(c) (tilgængelighed, integritet, fortrolighed) og art. 9 (beskyttelse og forebyggelse) |
| Kunde-administreret kryptering (BYOK) | Under udvikling | Understøtter art. 30(2)(c) ved at give kunden kontrol over krypteringsnøgler. Indtil tilgængelig administreres nøgler af syv.ai/applikationen, jf. Dataflow §6 |
| Multifaktor-autentificering (MFA) på applikationsniveau | På roadmap | Supplerer art. 30(2)(c) og kundens egen art. 9-ramme. SSO/proxy-baseret MFA kan implementeres af kunden indtil da |
4. DORA art. 30(2) obligatoriske kontraktelementer
Tabellen mapper hvert litra i art. 30(2) til den dokumentation eller platformfunktion, der opfylder kravet. Kunden kan bruge tabellen ved sin egen kontraktgennemgang og ved udfyldelse af registeret af information (art. 28(3)).
| Art. 30(2) | Krav | Hvor det opfyldes |
|---|---|---|
| (a) | Klar og fuldstændig beskrivelse af alle funktioner og ICT-ydelser, der leveres | Systembeskrivelse §1.2 (tilsigtet formål) og §2 (komponenter) |
| (b) | Lokationer, herunder regioner eller lande, hvor de aftalte funktioner og ICT-ydelser leveres, og hvor data behandles, samt krav om forudgående meddelelse ved ændring af lokation | Dataflow §4 (opbevaringssteder), §5 (EU-grænser); Underdatabehandlere. Ændringer i underdatabehandlere varsles med mindst 30 dage, jf. Databehandleraftalen Bestemmelse 7.3 |
| (c) | Bestemmelser om tilgængelighed, autenticitet, integritet og fortrolighed for data, herunder personoplysninger | Systembeskrivelse §6 (nøjagtighed, robusthed, cybersikkerhed); Dataflow §6 (kryptering) |
| (d) | Bestemmelser om beskyttelse af personoplysninger | Databehandleraftalen standardkontraktsbestemmelser efter GDPR art. 28, stk. 3 |
| (e) | Adgang, gendannelse og returnering af personoplysninger og andre data ved ophør | §7 i denne erklæring (Exit-strategi); Databehandleraftalen Bestemmelse 11 |
| (f) | Beskrivelser af servicelevels og opdatering heraf | Standardiseret SLA er ikke en del af den nuværende kontrakt. Konkrete servicemål tilgængelighed, RTO/RPO, supportresponse kan aftales individuelt ved kontraktindgåelse. Operationelle mål, der gælder uden særskilt aftale, fremgår af NIS2-erklæringen §4 |
| (g) | Forpligtelse for ICT-tredjepartsudbyder til at yde bistand i forbindelse med ICT-relaterede hændelser uden ekstra omkostninger eller til omkostninger fastsat på forhånd | §3 i denne erklæring + NIS2-erklæringen §3 + Databehandleraftalen Bestemmelse 9 |
| (h) | Forpligtelse for ICT-tredjepartsudbyder til at samarbejde fuldt ud med kundens kompetente myndigheder og kundens afviklingsmyndighed | §6 i denne erklæring; Databehandleraftalen Bestemmelse 4 (instruks) og Bestemmelse 12 (revision) |
| (i) | Rettigheder til opsigelse og minimumsvarslingsperioder | Databehandleraftalen Bestemmelse 14 regulerer ophør i forhold til databehandlingen. Opsigelse af den kommercielle hovedaftale aftales individuelt; ved ophør udløses exit-procedure (§7) |
| (j) | Vilkår for ICT-tredjepartsudbyderens deltagelse i kundens uddannelses- og bevidsthedsprogrammer om ICT-sikkerhed og digital operationel modstandskraft | syv.ai medvirker uden ekstra omkostninger ved kundens interne uddannelses- og bevidsthedstiltag, der berører AgentBase fx ved at deltage i kick-off, levere materiale om platformens sikkerhedsmodel og besvare spørgsmål fra kundens compliance- og sikkerhedsfunktion |
5. DORA art. 30(3) supplerende krav for kritiske/vigtige funktioner
Tabellen nedenfor gælder, hvis kundens klassifikation efter §2 fastslår, at AgentBase understøtter en kritisk eller vigtig funktion.
| Art. 30(3) | Supplerende krav | Hvor det opfyldes |
|---|---|---|
| (a) | Fyldestgørende beskrivelse af servicelevels med præcise kvantitative og kvalitative mål inden for området; tilladelse til at indføre korrigerende foranstaltninger ved manglende opfyldelse | Konkrete servicemål aftales individuelt ved kontraktindgåelse, jf. art. 30(2)(f). Korrigerende foranstaltninger og eskaleringsveje aftales samme sted |
| (b) | Varslingsperioder og rapporteringsforpligtelser for ICT-tredjepartsudbyderen til kunden, herunder underretning om udvikling, der i væsentlig grad kan påvirke leverancen | Hændelses- og ændringsvarsling er beskrevet i §3 i denne erklæring og i NIS2-erklæringen §3. 30-dages varsel ved ændringer i underdatabehandlere, jf. Databehandleraftalen Bestemmelse 7.3 |
| (c) | Krav om at ICT-tredjepartsudbyderen indfører og tester forretningsmæssige beredskabsplaner og har ICT-sikkerhedsforanstaltninger og protokoller, der er passende for at sikre kundens leverance | Backups testes via automatiseret indlæsning i adskilt miljø. Cybersikkerhedsforanstaltninger, jf. Systembeskrivelsen §6.3. Yderligere test-evidens kan udleveres efter aftale (§6 i denne erklæring) |
| (d) | Forpligtelse for ICT-tredjepartsudbyderen til at deltage i og fuldt ud samarbejde med kundens digitale operationelle modstandskrafttest, jf. art. 26 og 27 | syv.ai medvirker uden ekstra omkostninger ved kundens scenarie-baserede tests og afgrænsede penetrationstests af AgentBase i kundens kontekst. Trådets-ledet penetration testing (TLPT) efter art. 26 koordineres med syv.ai i god tid, så vinduer og scope kan aftales TLPT-testen og dens afrapportering er kundens ansvar |
| (e) | Ret til løbende at overvåge ICT-tredjepartsudbyderens ydelse, herunder uhindret adgang, inspektion og audit ved kunden eller en uafhængig tredjepart udpeget af kunden, samt af kompetente myndigheder | §6 i denne erklæring; Databehandleraftalen Bilag C.7 og C.8 |
| (f) | Exit-strategier herunder en obligatorisk passende overgangsperiode | §7 i denne erklæring |
6. Audit-, inspektions- og myndighedsret
Følgende ret er sikret kunden og kundens kompetente myndigheder efter DORA art. 30(3)(e):
| Forhold | Vilkår |
|---|---|
| Kundens egen revision | Skriftlig anmodning med mindst 30 dages varsel. Hyppighed: én gang årligt; hyppigere ved konkret begrundet behov. Omkostninger ved revisionen afholdes som udgangspunkt af kunden, jf. Databehandleraftalen Bilag C.7 |
| Kundens udpegede tredjepartsrevisor | Samme procedure som ovenfor. syv.ai kan modsætte sig en konkret revisor alene på baggrund af interessekonflikt ikke generelt |
| Kompetente myndigheder | syv.ai samarbejder fuldt ud og uden unødigt ophold med kundens kompetente myndigheder (i Danmark Finanstilsynet) og kundens afviklingsmyndighed efter art. 30(2)(h). Anmodninger formidles via kunden eller direkte fra myndigheden |
| Inspektion af underdatabehandlere | Underdatabehandlerne er større leverandører, der ikke tilbyder individuel revision; tilsynet sker via DPA'er og offentligt tilgængelig dokumentation og certificeringer, jf. Underdatabehandlere §4. syv.ai bærer fuldt ansvar over for kunden for underdatabehandlernes overholdelse |
| Adgang og dokumentation | Logudtræk, systembeskrivelser, sikkerhedspolitikker, DPA'er med underdatabehandlere, sårbarheds- og hændelsesoversigter udleveres på skriftlig anmodning |
7. Exit-strategi (art. 28(8))
DORA art. 28(8) kræver, at kunden har en dokumenteret exit-strategi for kritiske eller vigtige funktioner. Følgende gør AgentBase tilgængeligt for kunden ved ophør:
| Forhold | Vilkår |
|---|---|
| Eksport af agents og konfiguration | Agents, apps og versionshistorik kan eksporteres i JSON-format via platformens REST-API. Strukturen er dokumenteret i den offentlige OpenAPI-spec |
| Eksport af kørselsdata | Kørselshistorik (input, output, fejl, status pr. node, tidsstempler) kan eksporteres som JSON via API'et eller som strukturerede logs (LOG_JSON=true) |
| Eksport af uploadede dokumenter | Originaldokumenter kan hentes via API'et i deres oprindelige format |
| Eksport af brugerdata | Brugeroplysninger (e-mail, rolle, team ikke adgangskoder) kan eksporteres via API'et |
| Overgangsperiode | syv.ai stiller platformen til rådighed i en passende overgangsperiode efter opsigelse som udgangspunkt 3 måneder så kunden kan gennemføre migration. Længden kan aftales individuelt afhængigt af kundens migrationsplan |
| Sletning efter ophør | Efter overgangsperioden slettes kundens data inden 30 dage. Sletteattest fremsendes til kunden, jf. Databehandleraftalen Bestemmelse 11 |
| Bistand ved migration | syv.ai bistår mod et på forhånd aftalt timeforbrug med teknisk migration: dataeksportbatch, formatvejledning og eventuel hjælp til kundens nye leverandør. Almindelige hændelsesnotifikationer og samarbejde med myndigheder er omkostningsfrit, jf. art. 30(2)(g) |
8. Information til kundens register af information (art. 28(3))
Kunden er forpligtet til at føre et register af information over alle ICT-tredjepartsleverancer. Felterne nedenfor kan kopieres direkte ind i kundens register.
| Felt | Værdi |
|---|---|
| Leverandørens juridiske navn | syv.ai ApS |
| CVR-nummer | 44671247 |
| Juridisk hjemsted | Middelfartgade 18, 2100 København Ø, Danmark |
| LEI-kode | Ikke tildelt (syv.ai er ikke en regulerede finansiel entitet) |
| Land for hovedkontor | Danmark |
| Ydelsens navn | AgentBase |
| Beskrivelse af ICT-ydelsen | Software-as-a-service-platform til opbygning og kørsel af automatiserede arbejdsgange (DAGs) med integration til godkendte LLM- og OCR-leverandører. Se Systembeskrivelse §1.2 |
| Lokationer, hvor ydelsen leveres | EU/EØS primært Tyskland (hosting), Irland og Frankrig (eksterne underdatabehandlere). Se Dataflow §4–5 |
| Behandling sker uden for EU/EØS | Nej |
| Sub-outsourcing-kæde | Hetzner Online GmbH (DE), OpenAI Ireland Ltd. (IE), Mistral AI SAS (FR), Lettermint B.V. (NL/FR). Se Underdatabehandlere |
| Status som kritisk ICT-tredjepartsudbyder (CTPP) efter art. 31 | Ikke udpeget |
| Kontaktpunkt for hændelser | mads@syv.ai |
| Eksisterende DPA | Standardkontraktsbestemmelser i overensstemmelse med GDPR art. 28, stk. 3 |
| Exit-procedure dokumenteret | Ja, jf. §7 i denne erklæring |
9. Kontakt
Spørgsmål til denne erklæring, anmodning om kopi af indgåede underdatabehandleraftaler, dokumentation til kundens DORA-tilsyn eller henvendelser om sikkerhedshændelser kan rettes til:
syv.ai ApS Middelfartgade 18, 2100 København Ø CVR 44671247 E-mail: mads@syv.ai
10. Revisionshistorik
| Version | Dato | Ændring | Ansvarlig |
|---|---|---|---|
| 1.0 | 2026-05-18 | Første udgave af DORA-erklæringen for AgentBase. | syv.ai |