Data Protection
Kertos
EU-Made Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Kertos GmbH · www.kertos.io
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Kertos, from Kertos GmbH of Munich and Berlin, is a data protection and compliance platform. Its strongest score, 7 for integrations and automation, rests on over 100 claimed integrations, a published API reference, webhook documentation for data subject requests, HR-driven onboarding, ticketing and device sync, and monthly discovery scans. Audit readiness follows at 6-7 on a well-documented auditor view — read-only, with company-specific aliases for auditors reviewing several companies — plus automatic evidence collection linking policies to controls. Privacy management sits at 6: records of processing, DPIA, TOM and TIA on one platform, with legal bases, DPIA triggers and group templates unevidenced. Data subject requests are documented to GDPR Articles 15-19 with a 30-day default due date and per-system tasks; the incident side is a module name. The widest spreads: framework coverage at 4-6 (breadth including EU AI Act modules versus no public information on UK GDPR, Swiss nDSG or ePrivacy) and sovereignty at 2-4 (a verifiable German entity versus no public information on hosting, a DPA or subprocessors). Public pricing is absent and pricing transparency is not counted.
Speaks for it
- Over 100 claimed integrations plus a published API reference and webhook documentation for data subject requests
- A read-only auditor view with company-specific aliases for auditors reviewing several companies
- Data subject request handling documented to GDPR Articles 15-19 with a 30-day default due date and per-system tasks
- Records of processing, DPIA, TOM and TIA built on one platform and fed by automated tool and data discovery
- Automatic evidence collection linking completed policies to controls with evidence attached
Held against it
- We found no public information on hosting location, a published data processing agreement or a subprocessor list
- The incident side appears as a module name, with no public information on a 72-hour breach clock, severity assessment or an authority notification output
- We found no public information on UK GDPR, Swiss nDSG or ePrivacy coverage, or on whether one processing record maps across regimes
- We found no public information on revision-safe change history or on reconstructing the state of the documentation on a past date
- We found no public pricing on any captured page, including for the optional external DPO add-on
Best for
- You build GDPR documentation — records of processing, DPIA, TOM and TIA — and want the register fed by automated discovery of tools and data sources instead of manual entry
- You handle data subject requests at volume and want a documented per-system workflow with API and webhook intake
- You bring external auditors, or an external data protection officer via the optional add-on, into the platform and need read-only access with company-specific aliases
- You are working to GDPR and the EU AI Act together and need AI inventory, AI assessment and an AI management system as product modules
Avoid if
- Your procurement requires a published data processing agreement, a subprocessor list and a stated hosting location before signing — sovereignty scored 2-4 and we found no public information on these
- You must cover UK GDPR, Swiss nDSG or ePrivacy alongside GDPR — the captured framework lists name ISO 27001, NIS2, GDPR, ISO 42001, SOC 2, TISAX, ISO 27701, EU AI Act and C5
- You run a multi-client audit or DPO practice and want one build serving several mandates — each reviewed company is a separate account with its own alias
The scores
Records & DPIA depth
Show reasoningHide reasoning
How this is scored
The DSMS core: records of processing (RoPA/VVT), data protection impact assessments, processor/DPA management and TOMs — how deeply the legal artifacts are modeled and connected.
0 — Document templates in a folder tree; the "register" is a Word file with version numbers in the filename.
3 — A structured RoPA with basic fields and a DPIA questionnaire, but processors, TOMs and legal bases live outside the system.
5 — RoPA and DPIA as linked modules with templates; processor management and TOM assignment exist but are shallow, and group reuse is copy-paste.
8 — A connected data model — processing activities linked to systems, processors, TOMs and legal bases — with DPIA triggers derived from the record, reusable group templates, and outputs a supervisory authority accepts.
10 — Privacy records as a system of record: the RoPA drives DPIAs, processor management and TOM coverage from one data model, multi-client/mandate capability included, and the documentation is audit-ready without manual assembly.
The External DPO
RoPA, DPIA, TOM and TIA on a single platform with vendor management and automated discovery feeding the record is a workable engine for one mandate. I found no public information on DPIA triggers derived from the record, legal-basis modeling, reusable group templates, or any multi-mandate capability — the auditor feature treats each reviewed company as a separate account — so for a thirty-client practice this stays a per-client build. 6 7 10 12
The In-House Counsel
Records of processing, DPIAs, TOMs and transfer impact assessments run on one platform, with automated discovery feeding the record and a vendor register and TOM catalogs alongside. What I could not find is the connected legal data model my files depend on — legal bases on the record, DPIA triggers derived from it, or reusable group templates — so this is more than a basic register but not yet an authority-acceptable core. 6 7 10 12
The Drafted Generalist
Records of processing, impact assessments, TOMs and transfer impact assessments are built on one platform, and the register gets filled by automatic discovery of tools and data sources rather than by me typing it in. I found no public information on legal bases wired into the record, assessments triggered from it, group-wide reusable templates, or outputs a supervisory authority has accepted. 6 10 7
The Lead Auditor
RoPA, DPIA, TOM and TIA are all created on a single platform, discovery scans feed the records, and the auditor view confirms these are real modules with their own catalogs alongside a vendor management module. But the connective tissue I audit for is unevidenced: we found no public information on legal bases carried on the record, DPIA triggers derived from it, reusable group templates, or processor depth beyond the module name. Solid linked modules with linkage depth unproven. 6 7 10 12
The IT Integrator
Records of processing, DPIAs, TOMs and transfer impact assessments are built on one platform, the record of processing is fed by automated tool and data discovery, and vendor management sits beside it — a real register, not a folder tree. The connective depth is unproven though: I found no public information on processing activities linked to legal bases, DPIA triggers derived from the record, or reusable group templates, and the auditor view confirms the modules exist without showing the data model between them. 6 7 10 12
The Skeptic
RoPA, TOM, DPIA and TIA are named as creatable on one platform, confirmed as readable modules in the auditor view alongside vendor management, with discovery and website scans feeding the records rather than pure typing. But we found no public information on legal bases, DPIA triggers derived from the record, reusable group templates, or multi-client capability — "with just a few clicks" is marketing where I want a data model. 3 6 7 10 12
Data subject rights & incidents
Show reasoningHide reasoning
How this is scored
The operational half of the DSMS: data subject request handling with statutory clocks, breach register and authority notification, deletion concepts that actually delete.
0 — Requests arrive by email and live there; breaches are a phone call and a memo.
3 — A request log and a breach list exist, but deadlines are manual, intake is unstructured, and deletion rules are documentation rather than workflow.
5 — DSR workflows with the Art. 12 clock tracked, structured breach register with the 72-hour clock, deletion concepts assignable to records; automation is reminders.
8 — Intake channels for requests (portal/form), identity-check support, deadline automation with escalation, breach severity assessment and authority-report output, deletion rules tied to the RoPA with execution tracking.
10 — Rights and incidents as operations: end-to-end request handling an authority audit walks through, breach workflows that produce the Art. 33 notification, and deletion automation with evidence that the deletion happened.
The External DPO
The rights half is genuinely operational: Articles 15–19 request types, per-system execution tasks with automatic status, a 30-day default deadline, API ingress plus webhook documentation, and deletion requests automated through data-source APIs. The incident half appears only as a module name in the module list — I found no public information on a 72-hour clock, severity assessment, or an authority-report output. 6 8 10 15
The In-House Counsel
Data subject request handling is documented in operational depth — Articles 15 to 19, a 30-day default deadline, per-system execution tasks with automatic status, and API and webhook intake from receipt to confirmation. An incidents module is named, but I found no public information on a 72-hour breach clock, severity assessment, or an output that becomes the Article 33 notification to the authority. 8 10 12 15
The Drafted Generalist
Request handling is real operations: all the GDPR request types, a 30-day deadline that is tracked and adjustable, per-system execution tasks, automatic closing once every system reports back, plus API and webhook documentation for automation. I found no public information on identity checks, escalation when the clock runs down, or whether the incident module tracks the 72-hour breach clock and produces the authority notification. 8 10 12
The Lead Auditor
The request workflow is operational, not a log: five request types under Articles 15 to 19, a 30-day default due date, per-system execution tasks with assignment, and a status that closes itself only once the data subject has been answered, with API, webhook and request-automation intake documented. The breach half rests on a module name alone in the captures: we found no public information on a 72-hour clock, severity assessment, authority notification output, or identity checks for requesters. 8 9 10
The IT Integrator
Request handling is operational: GDPR Articles 15 to 19 request types, a tracked default 30-day due date, per-system execution tasks that gate the status before anything goes to the data subject, staff assignment, tags, attachments, documented ingress API and webhook endpoints, and the stated intake-to-confirmation automation. For the incident side I found no public information on a 72-hour clock, authority-report output or requester identity checks — only a named incident-management module — and deletion is tracked as per-system tasks rather than rules tied to the register. 8 6 10 15
The Skeptic
The documentation shows a genuine request workflow — types mapped to GDPR Articles 15–19, a default 30-day due date, per-system tasks with assignees, a status flow that closes itself when the response email sends, plus ingress and webhook API docs. The breach half is a module name and nothing more: we found no public information on a 72-hour clock, severity assessment, an Art. 33 notification output, data-subject-facing intake, or identity verification. 8 10 12
Privacy regime coverage
Show reasoningHide reasoning
How this is scored
Which privacy regimes the product actually operationalizes — GDPR, BDSG, Swiss nDSG, UK GDPR, ePrivacy, EU AI Act privacy duties — and whether one record maps across them or each regime is a fresh island.
0 — One regime, hard-coded; anything else is "on the roadmap".
3 — GDPR plus one national law as separate checklists; the same processing activity is documented once per regime.
5 — The major regimes for its market with partial cross-mapping; newer duties (AI Act, ePrivacy changes) present as content packs of varying depth.
8 — Broad current coverage with one-record-many-regimes mapping and visible maintenance as regimes evolve.
10 — Regime coverage as a living product: multiple privacy regimes on one data basis, per-country variants, and documented update cadence when the law moves.
The External DPO
GDPR is deeply built out and the EU AI Act side is real product — AI inventory, assessments, employee trainings — alongside NIS2, ISO 27701, TISAX and C5, which is strong European breadth. But the privacy-regime set stops there: I found no public information on Swiss nDSG, UK GDPR or ePrivacy, and nothing on whether one processing record maps across regimes or has to be documented once per regime. 1 4 7 11
The In-House Counsel
GDPR is deeply operationalized with a dedicated management system and an optional Article 37 data protection officer, and the EU AI Act carries real content — AI inventory, assessment and use-case documentation rather than a roadmap mention. Beyond those the captured pages show security certifications, not privacy regimes: I found no public information on BDSG, Swiss nDSG, UK GDPR or ePrivacy, and no evidence that one processing record maps across regimes. 1 4 10 11
The Drafted Generalist
GDPR is covered end to end and the EU AI Act is more than a content pack — an AI inventory, assessments, an AI management system and employee trainings are actual modules, with ISO 27701 on the list too. I found no public information on BDSG, Swiss or UK variants, ePrivacy duties, or whether one record maps across regimes instead of being documented once per framework. 1 11 7
The Lead Auditor
GDPR is deeply productized — dedicated VVT, DSFA and TOM pages plus an external DPO add-on working in the same platform — and the EU AI Act carries real modules in AI inventory, assessment and AIMS. Beyond those two regimes the captured pages go quiet: we found no public information on BDSG, Swiss nDSG, UK GDPR or ePrivacy coverage, nor any evidence that one processing record maps across regimes rather than being documented per framework. 1 10 11 13
The IT Integrator
GDPR is operationalized end to end (RoPA, DPIA, TOM, request automation) and the EU AI Act is a real product surface — AI inventory, AI assessment, AIMS and structured use-case documentation — with NIS2, ISO 27701, TISAX and C5 in the framework list. What holds it back: I found no public information on one record mapping across regimes, on per-country variants, or on UK GDPR, Swiss nDSG or ePrivacy. 1 11 9 6
The Skeptic
The fuller homepage list names nine frameworks including the EU AI Act with substantive modules (AIMS, AI inventory, AI assessment) and a dated product update adds AI Act use-case documentation — breadth plus visible maintenance. The captured pages give different framework lists, though, and we found no public information on UK GDPR, Swiss nDSG, ePrivacy, per-country variants, or whether one processing record maps across regimes rather than being documented framework by framework. 1 4 11 13
Audit readiness & evidence
Show reasoningHide reasoning
How this is scored
Whether the system produces defensible proof: revision-safe history, evidence collection, reports for auditors, authorities and management.
0 — Exports are screenshots; history is overwritten in place.
3 — PDF reports exist but evidence is attached ad hoc and changes leave no reliable trail.
5 — Versioned records, standard report generators for the core registers, evidence attachments per activity; assembling a full audit file still takes days.
8 — Revision-safe change history, audit-scoped evidence packs on demand, management and authority reports current at a click, auditor access roles.
10 — Audit readiness as a standing state: continuous documentation status per regime and scope, exportable proof packs an auditor accepts as-is, and a defensible answer to "show me the state on date X".
The External DPO
The auditor role is the best-evidenced capability on the vendor's pages — read-only access across records, TOMs, DPIAs, data subject requests and incidents, configuration hidden, and company-specific aliases when the same auditor reviews several companies, which is exactly my world. Automatic evidence collection linking policies to controls exists today, with trainings, incidents and risks announced as next steps; I found no public information on revision-safe change history or a state-on-a-given-date export. 12 13
The In-House Counsel
There is a genuine auditor role — read-only, invitation-based, with company-specific aliases for auditors covering several companies and exclusion from workflow assignment — plus automatic evidence collection that links completed policies to controls. What I could not find is the defensibility core: revision-safe change history or the ability to show the state of the documentation on a given date, so the audit file is not yet a standing state. 12 13
The Drafted Generalist
The auditor role is unusually well thought out — read-only access to records and evidence, an invitation flow, company-specific aliases for auditors serving several clients, and exclusion from task workflows — and policies now automatically mark controls complete and attach the evidence. I found no public information on revision-safe change history or reconstructing the state on a past date, and the automatic evidence collection is new and still being extended to incidents, risks and assets. 12 13
The Lead Auditor
The auditor role is thoughtfully built — true read-only access to records and evidence, configuration walled off, auditors excluded from workflow assignments, company-specific aliases for multi-company reviewers — and new automatic evidence collection links completed policies to controls. But we found no public information on revision-safe change history, exportable evidence packs, or any way to reproduce the state as of a past date, and the evidence automation itself covers only policies and controls today with other areas announced for later. 12 13
The IT Integrator
The auditor experience is engineered, not bolted on: a read-only role covering inventory, compliance, privacy and risk records with evidence, company-specific email aliases when one auditor reviews several companies, and exclusion from owner, approver, policy or training assignments. Automatic evidence collection links finished policies to controls with evidence attached, and vulnerability remediation can be turned into audit evidence. I found no public information on revision-safe change history, audit-scoped evidence packs on demand, or a defensible answer to the state of records on a given date. 12 13 14
The Skeptic
The auditor view is the best-evidenced thing here: read-only, role-restricted, with automatically created company-specific aliases for auditors reviewing several clients — real documented behavior, not a badge. The evidence automation is new and its own announcement says it will be extended to further areas later, and we found no public information on revision-safe change history, exportable evidence packs, or reconstructing the state on a past date. 12 13
Integrations & automation
Show reasoningHide reasoning
How this is scored
Whether the platform feeds from the real IT estate — directory import, ticketing, API — and automates the recurring privacy work instead of re-typing it.
0 — A closed island: manual entry in, PDF out, no API.
3 — CSV/Excel import and export; no live connections, no API worth the name.
5 — Directory import (AD/Entra), a documented REST API for core objects, a handful of native connectors (ticketing or SSO); automation is reminders and recurrence.
8 — Real connector set (ticketing, HR or asset sources), webhooks, SSO/SCIM, workflow automation with delegation and escalation, useful AI assistance with human review.
10 — The platform behaves like infrastructure: API parity for the data model, event streams, bidirectional sync with the estate, and automation that measurably removes the recurring toil (reviews, attestations, evidence pulls) rather than renaming it.
The External DPO
Over one hundred claimed integrations, documented connectors for ticketing sync, HRIS user onboarding, device-to-asset sync and discovery scans, a public API reference, webhook documentation for data subject requests, and an AI assistant — this feeds from the estate instead of re-typing it. I found no public information on SSO/SCIM or escalation logic, and API parity with the full data model is not shown. 7 11 14 15
The In-House Counsel
Over one hundred integrations are claimed, with a documented API reference, webhook documentation for data subject requests, HRIS-driven user provisioning, ticketing and device sync, and monthly discovery scans feeding the registers — the estate feeding the system rather than re-typing. I found no public information on SSO/SCIM or escalation automation, which keeps this short of infrastructure-grade. 8 11 14 15
The Drafted Generalist
More than one hundred integrations with documented connectors for ticketing, HR systems, device management and vulnerability scanning, an API reference, webhooks for data subject requests, and monthly discovery scans — the IT estate feeds the platform instead of me retyping it. I found no public information on single sign-on, user directory sync, or escalation rules, which is what I would need to see next. 14 15 11
The Lead Auditor
The platform feeds from the real estate: over 100 integrations, a public API reference, webhook and ingress API docs for data subject requests, ticketing sync, HRIS-driven user onboarding, device-to-asset sync, monthly discovery scans, and vulnerability remediation converted into audit evidence. The captures are silent on SSO and SCIM provisioning, on delegation and escalation within workflows, and on any human-review step around the KAIA assistant. 7 11 14 15
The IT Integrator
Over one hundred integrations, a published API reference, webhook documentation for data subject requests, HRIS connections that add joining users automatically, task sync with ticketing tools, device sync into the asset inventory and monthly discovery scans — this platform syncs with the estate instead of demanding a CSV drawbridge, and a customer reports connecting homegrown software via API in an afternoon. Still, I found no public information naming SSO or SCIM (an Authentication settings tab exists but undescribed), AD or Entra directory import by name, escalation paths, or bidirectional sync — so it sits just under the top bench. 11 15 14 12 10
The Skeptic
Named integration categories — ticketing task sync, HR systems auto-adding users, device sync into the asset inventory, vulnerability remediation turned into audit evidence — plus a published API reference and webhook/ingress documentation put this above an import/export story. But "über 100 Integrationen" is a bare number with no connector list behind it, KAIA the "Artificial Intelligence Agent" exists so far only in slogans, and we found no public information on SSO/SCIM or escalation automation. 7 11 14 15
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where the compliance record of the whole company actually lives and under whose law — entity, hosting, subprocessors, DPA. A platform that maps your processing is itself your most concentrated processing.
0 — Non-EU entity, non-EU-default hosting, no public DPA or subprocessor list — for the system holding your RoPA.
3 — A DPA exists and an EU region is available on request or on top tiers; subprocessor exposure to US CLOUD Act reach is broad or undocumented.
5 — EU hosting is the default, DPA and subprocessor list published; the vendor or a critical subprocessor is still within non-European jurisdictional reach.
8 — EU entity, EU hosting with named data centers, published subprocessor list free of content-touching non-EU processors, DPA and TOMs public.
10 — Jurisdictionally clean end to end: European ownership, EU-only hosting and subprocessors, on-premises or sovereign-cloud options, and the whole chain documented publicly.
The External DPO
The imprint confirms a German GmbH in Munich and Berlin with German registry and VAT details, "Made in Germany", and EU co-financing, so the entity side is clean. For the platform that would hold my clients' records of processing, I found no public information on hosting location, a published data processing agreement, or a subprocessor list — and that gap decides the score. 5 6 7
The In-House Counsel
The entity is verifiable and German — a GmbH registered at the Munich court with a registration number, offices in Munich and Berlin, and a Made in Germany positioning. But this platform would hold our entire record of processing, and I found no public information on hosting location, a data processing agreement or a subprocessor list, which for our most concentrated processing I cannot defend without. 5 4 11
The Drafted Generalist
The imprint confirms a German company registered in Munich with a German VAT number, and the pages carry a Made in Germany claim, so the vendor itself is European. But for the system that would hold my entire record of processing, I found no public information on hosting locations, a data processing agreement, the subprocessor list, or ownership — and the help documentation itself runs on a third-party platform. 5 6 11
The Lead Auditor
The imprint is solid German paperwork — a GmbH registered at the Munich court with an HRB number, a VAT ID, offices in Munich and Berlin — but everything deciding where my compliance record actually lives is undocumented: we found no public information on hosting region, a DPA, or a subprocessor list, and the documentation itself runs on a third-party platform. "Made in Germany" is a label, not a data residency statement, and for the platform that would hold the RoPA this silence is the finding. 5 11 15
The IT Integrator
The entity is firmly European: a Kertos GmbH registered at the Munich court with an HRB number, a German VAT ID, offices in Munich and Berlin, "Made in Germany" claims and EU co-financing. But we found no public information on hosting location or named data centers, a published DPA, or a subprocessor list — the chain under the system that would hold my record of processing is undocumented, and ownership is unverified in these captures. 5 11 7 4
The Skeptic
The imprint capture puts a German GmbH, Munich registry court and HRB number behind the product, and "Made in Germany" appears as a label — but a label is not a data center address. We found no public information on hosting location, data residency, subprocessors, a public DPA, or the VC ownership behind the company; for the platform that maps your processing, its own chain is undocumented. 5 11
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real invoice — per module, per entity, per year, with consulting unbundled — from public pages alone. Unpublished pricing is the B2B norm in this market, so this criterion describes rather than condemns; the benches weight it accordingly.
0 — No public prices at all; every configuration is a sales conversation.
3 — An entry price exists, but module add-ons, entity counts or bundled consulting make the real total incomputable.
5 — Most editions carry real numbers with billing period stated and software separated from services; at least one commonly needed module or scale step is unpriced.
8 — Every edition and module priced publicly with entity/user boundaries and setup fees stated; only genuine corporate-group contracts are custom.
10 — Complete price computability: modules, scale steps, service packages and renewal rules public, so the invoice for a 100-employee company and a 10-client consultancy is a two-minute exercise.
The External DPO
I found no public pricing information on any captured page — no editions, no per-module figures, no billing period, nothing on the external DPO add-on's rate. Computing an invoice for a single client, let alone a ten-client consultancy, is a sales conversation rather than a two-minute exercise; the market norm explains this but the anchor for total silence is the anchor for total silence. 1 2
The In-House Counsel
I found no public pricing information on any captured page — no edition prices, no module prices, no setup fees, and the optional external data protection officer service is offered without a number. Every real invoice, including the DPO add-on, is a sales conversation; normal for this market, but not computable by a buyer from these pages. 2 10
The Drafted Generalist
I found no public prices at all — no edition or module figures, no setup fees, no billing period — and even the optional external data protection officer is offered as a bookable add-on with no number attached. Any budget exercise starts with a sales call. 10 3
The Lead Auditor
We found no pricing information of any kind across the captured product, platform and company pages — no editions, no per-module figures, no billing periods, no setup fees — so the real invoice is computable only in a sales conversation. That is the B2B norm in this market and I record it as a description, not a scandal. 2 4
The IT Integrator
I found no public pricing information on the captured platform, product and framework pages — no edition or module prices, no user or entity tiers, no billing period, no setup or service fees — so a buyer cannot compute an invoice from public pages alone. 7 11
The Skeptic
We found no public pricing on any captured page — no editions, no per-module prices, no billing period, no separation of software from the external-DPO add-on. The homepage sells outcomes like "100% Auditerfolg" where a starting price would go; every configuration appears to be a sales conversation. 2 1
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 31 Aug 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Legal entity. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We found no public information on pricing on the pages we read (kertos.io/en, kertos.io/en/platform, kertos.io/en/frameworks/gdpr, kertos.io/en/about-us, kertos.io/en/imprint, kertos.io/plattform/vvt and 9 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 74 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 11 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 11 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 7 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 hosting facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 sovereignty dimension could not be confirmed on the vendor’s own pages and is shown as unknown. Know more? Tell us
Sources (15)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.kertos.io Checked 16 Sep 2026 +1 earlier capture: 15 Sep 2026 Details →
- 2 Platform page www.kertos.io Checked 16 Sep 2026 Details →
- 3 GDPR framework page www.kertos.io Checked 16 Sep 2026 +1 earlier capture: 31 Aug 2026 Details →
- 4 About page www.kertos.io Checked 16 Sep 2026 +1 earlier capture: 31 Aug 2026 Details →
- 5 Imprint www.kertos.io Checked 16 Sep 2026 Details →
- 6 Records & DPIA depth — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 7 Records & DPIA depth — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 8 Data subject rights & incidents — found from sitemap docs.kertos.io Checked 1 Oct 2026 Details →
- 9 Data subject rights & incidents — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 10 Privacy regime coverage — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 11 Privacy regime coverage — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 12 Audit readiness & evidence — found from sitemap docs.kertos.io Checked 1 Oct 2026 Details →
- 13 Audit readiness & evidence — found from sitemap www.kertos.io Checked 1 Oct 2026 Details →
- 14 Integrations & automation — found from sitemap docs.kertos.io Checked 1 Oct 2026 Details →
- 15 Integrations & automation — found from sitemap docs.kertos.io Checked 1 Oct 2026 Details →