Einen Team-Browser bewerten: eine praxisnahe Prüfliste

Definieren Sie die Entscheidung, bevor Sie eine Preisseite öffnen

Eine sinnvolle Bewertung beginnt bei der Arbeit, nicht bei der Anbieterliste. Dokumentieren Sie:

• autorisierte Arbeitsabläufe und die Systeme, die sie erlauben;
• Anzahl der Personen, gespeicherten Profile, synchronisierten Profile und gleichzeitigen Browsersitzungen;
• unterstützte Betriebssysteme und Prozessorarchitekturen;
• benötigte Browser-Engines, Erweiterungen, Proxys, Identitätsanbieter und Automatisierungsclients;
• Pflichten zu Datenresidenz, Aufbewahrung, Export, Löschung und Audit;
• Erwartungen an Wiederherstellungszeit und hinnehmbaren Datenverlust;
• Anforderungen an die Barrierefreiheit für Bedienpersonen und Administratoren;
• Budget, Abrechnungszeitraum, Supportabdeckung und Ausstiegsbedingungen; sowie
• verbotene Arbeitsabläufe, die das Produkt für Ihr Team nicht ermöglichen darf.

Halten Sie Ressourcentypen getrennt. Ein Tarif mit 500 gespeicherten Profilen, 100 cloud-synchronisierten Profilen, fünf Plätzen und zehn gleichzeitigen Sitzungen bietet keine 500 parallelen Teamsitzungen. Übersetzen Sie jede Grenze in die Einheit, die Ihr Arbeitsablauf verbraucht.

Bestimmen Sie anschließend nicht verhandelbare Freigabekriterien. Ein verbreiteter Satz umfasst:

1. unterstützte, aktuelle Browser-Builds;
2. keine unbemerkte Profilbeschädigung oder gleichzeitigen schreibenden Prozesse;
3. persönliche Identitäten mit widerrufbarem Zugriff nach dem Prinzip der geringsten Rechte;
4. keine ungeschützten Geheimnisse in gewöhnlichen Protokollen oder Automatisierungsausgaben;
5. nutzbare Auditnachweise;
6. einen getesteten Wiederherstellungs- und Ausstiegsweg; sowie
7. rechtmäßige, autorisierte Nutzung im Einklang mit geltenden Dienstbedingungen.

Rechnen Sie ein fehlgeschlagenes Freigabekriterium nicht in einem numerischen Durchschnitt klein. Eine ausgefeilte Oberfläche gleicht weder einen ungeprüften Updater noch einen Wiederherstellungsprozess mit Zustandsverlust aus.

Verwenden Sie eine einfache Nachweisskala

Dokumentieren Sie für jeden Punkt der Prüfliste sowohl ein Ergebnis als auch den stärksten erhaltenen Nachweis.

Ergebnis

• Bestanden: Die genannte Anforderung wurde in der definierten Testumgebung nachgewiesen.
• Bedenken: Das Verhalten widerspricht der Anforderung oder schafft einen wesentlichen Zielkonflikt.
• Nicht geprüft: Nachweise fehlen, sind unzugänglich, veraltet oder zu mehrdeutig für eine Entscheidung.
• Nicht anwendbar: Die Anforderung gilt tatsächlich nicht für den Arbeitsablauf; der Grund ist dokumentiert.

Nachweis

1. Veröffentlichte Aussage: Marketing- oder Vertriebstext.
2. Technische Dokumentation: Versionierte Produkt-, Sicherheits-, API- oder Supportdokumentation.
3. Beobachtete Demonstration: Live-Demonstration des Anbieters anhand Ihres Szenarios.
4. Kontrollierter Test: Ihr Team reproduziert das Verhalten mit ersetzbaren Daten und dokumentiert Versionen und Ergebnisse.
5. Unabhängiger oder vertraglicher Nachweis: Abgegrenzte Bewertung, unterzeichnete Zusage oder Supportkondition, die die Anforderung abdeckt.

Ein höherer Nachweis ist nicht in jedem Fall automatisch besser. Ein unabhängiger Bericht kann den Desktop-Browser ausschließen, während ein kontrollierter Test ihn unmittelbar prüft. Dokumentieren Sie Umfang, Datum, Version und Einschränkungen jedes Artefakts.

1. Produktstatus und Aussagegrenzen

• □ Gibt es für jede benötigte Plattform und Architektur einen echten installierbaren Build?
• □ Kann der Anbieter die aktuelle Anwendungs- und Browserversion sowie das Releasedatum benennen?
• □ Sind Beta-, Vorschau-, experimentelle und allgemein verfügbare Funktionen getrennt gekennzeichnet?
• □ Stimmen Dokumentation und tatsächlicher Test bei Grenzen und Verhalten überein?
• □ Sind Aussagen zu Sicherheit, Verfügbarkeit, Verschlüsselung und Leistung auf konkrete Komponenten und Nachweise begrenzt?
• □ Sind bekannte Einschränkungen, nicht unterstützte Arbeitsabläufe und Regeln zum Supportende veröffentlicht?
• □ Vermeidet der Anbieter Garantien zu Unsichtbarkeit, Fortbestand von Konten oder Zugriff auf Dienste Dritter?

Erfassen Sie am Bewertungstag Installer, Versionsansicht, Releasenotizen und relevante Dokumentation. Eine Vertriebsantwort ohne stabilen Verweis bleibt eine veröffentlichte Aussage, kein geprüftes Verhalten.

2. Profilisolierung und -integrität

Definieren Sie zuerst, was das Produkt als Profil bezeichnet. Gemeint sein können ein dauerhaftes Browserdatenverzeichnis, ein temporärer Browserkontext, ein synchronisiertes Archiv, eine entfernte Sitzung oder eine Sammlung von Einstellungen. Diese Dinge sind nicht gleichwertig.

Chromium dokumentiert das Benutzerdatenverzeichnis als Speicherort für Benutzerdaten und erläutert, wie ein benutzerdefiniertes Verzeichnis ausgewählt wird. Die Dokumentation nennt außerdem Fälle, in denen zwei laufende Instanzen ein Verzeichnis nicht gemeinsam verwenden können. Nutzen Sie die vorgelagerte Dokumentation des Benutzerdatenverzeichnisses als Ausgangspunkt und fordern Sie anschließend produktspezifische Nachweise.

• □ Besitzt jedes dauerhafte Profil eine klar definierte Speicher- und Prozessgrenze?
• □ Verhindert das Produkt, dass zwei schreibende Prozesse denselben veränderlichen Profilzustand öffnen?
• □ Sind Cookies, Speicher, Cache, Verlauf, Erweiterungen, Downloads, Berechtigungen und Einstellungen wie dokumentiert isoliert?
• □ Sind temporäre Sitzungen und dauerhafte Profile unterschiedlich gekennzeichnet?
• □ Verwendet ein sauberer Start ausschließlich die vorgesehenen Profildaten?
• □ Bewahrt ein Neustart genau den Zustand, dessen Erhaltung das Produkt verspricht?
• □ Werden Berechtigungen und Installationsquellen von Erweiterungen kontrolliert?
• □ Werden Profilimporte als nicht vertrauenswürdige Eingaben behandelt und vor der Nutzung geprüft?
• □ Kann ein beschädigtes oder inkompatibles Profil isoliert werden, ohne eine bekanntermaßen intakte Kopie zu überschreiben?

Testnachweise sollten profilübergreifende Prüfungen enthalten. Setzen Sie eine harmlose Markierung in Profil A, bestätigen Sie ihr Fehlen in Profil B, starten Sie beide neu und wiederholen Sie den Test nach einem Anwendungsupdate. Verwenden Sie ersetzbare Konten und synthetische Daten.

3. Browseraktualität, Sandbox und Updates

Ein Browser ist eine fortlaufend gepflegte Sicherheitsabhängigkeit. Die aktuelle Kanaldokumentation von Chromium gibt an, dass Stable wöchentlich kleine und alle vier Wochen große Updates erhält. Dieser Releaserhythmus schreibt einem Anbieter kein genaues Servicelevel vor, zeigt aber, weshalb „Chromium-basiert“ ohne Versions- und Updatenachweise unvollständig ist.

• □ Lässt sich der Browser-Build des Produkts einer genauen vorgelagerten Version zuordnen?
• □ Gibt es ein veröffentlichtes Ziel oder einen Verlauf für die Übernahme vorgelagerter Sicherheitsupdates?
• □ Wer überwacht vorgelagerte Releases und dringende Korrekturen?
• □ Sind Anwendungs- und Browserupdates unabhängig von der Downloadverbindung signiert und authentifiziert?
• □ Können Sie Artefakt-Digests, Releaseherkunft oder eine gleichwertige Beweiskette prüfen?
• □ Werden Einführungen gestuft, überwacht und können sie angehalten werden?
• □ Vermeidet ein Rollback die Wiederherstellung einer Version, die nach der aktuellen Sicherheitsrichtlinie unsicher ist?
• □ Werden Profilschemamigrationen über unterstützte Upgrade- und Downgradepfade getestet?
• □ Bleibt die Browser-Sandbox im normalen Betrieb aktiviert?
• □ Kann der Anbieter nicht in einer Sandbox laufende oder privilegierte Prozesse und deren Notwendigkeit erklären?

Chromium beschreibt seine Sandbox als Grenze, die nicht vertrauenswürdigen Code einschränkt und das Prinzip der geringsten Rechte sowohl auf den eingeschlossenen Code als auch auf dessen Steuerung anwendet. Prüfen Sie das Chromium-Sandbox-Design und lassen Sie sich anschließend die tatsächliche Produktivkonfiguration des Anbieters zeigen. Die Aussage, ein Produkt „verwende Chromium“, belegt nicht, dass alle vorgelagerten Schutzmaßnahmen aktiviert bleiben.

Für die Updateintegrität ist The Update Framework ein hilfreicher Bezugspunkt, weil es die Kompromittierung von Repositories und Signaturschlüsseln ausdrücklich behandelt. SLSA Provenance definiert überprüfbare Angaben dazu, wo, wann und wie ein Artefakt erzeugt wurde. Ein Anbieter muss nicht genau diese Projekte verwenden, sollte aber erklären, wie sein Design Artefaktidentität, kompromittierte Schlüssel, Rollback, Freeze und Build-Herkunft behandelt.

4. Identität, Geräte und geringste Rechte

NIST SP 800-53 Rev. 5 ordnet Kontrollen nach Zugriffskontrolle, Audit, Authentifizierung, Notfallplanung, Vorfallreaktion und Lieferkettenrisiko. Verwenden Sie diese Familien als Prüfanregungen, statt die Übereinstimmung mit einem Framework als Umsetzungsnachweis zu behandeln.

• □ Erhält jede Person eine eigene Identität statt einer gemeinsam genutzten Teamanmeldung?
• □ Ist Mehrfaktorauthentifizierung für Administratoren und andere vertrauliche Rollen verfügbar und erzwingbar?
• □ Werden stärkere, phishingresistente Authentifizierungsoptionen unterstützt, wenn Ihr Risiko sie erfordert?
• □ Kann die Identität bei Bedarf mit Ihrem Anbieter föderiert werden, ohne die Produktautorisierung zu umgehen?
• □ Sind Rollen feingranular genug, um Anzeigen, Starten, Bearbeiten, Freigeben, Exportieren, Löschen, Abrechnung und Administration zu trennen?
• □ Kann der Zugriff auf eine Organisation, einen Arbeitsbereich, Ordner oder ausdrücklichen Profilsatz beschränkt werden?
• □ Können Gerät, Sitzung, Benutzer, Dienstzugangsdaten oder Einladung zeitnah widerrufen werden?
• □ Besitzen Dienstkonten eigene Identität, Ablaufzeit, Berechtigungsumfänge und Ratenbegrenzungen?
• □ Sind Berechtigungsänderungen und fehlgeschlagene Autorisierungsversuche im Auditverlauf sichtbar?
• □ Entfernt das Offboarding den Zugriff, ohne dass ein gemeinsames Passwort geändert werden muss?

Aktuelle Authentifizierungsterminologie und Vertrauensniveaus finden Sie in NIST SP 800-63B-4, finalisiert am 31. Juli 2025. Prüfen Sie, welche Produktbereiche die Authentifizierungsaussagen des Anbieters abdecken: Websiteanmeldung, Desktop-Entsperrung, lokale API, Cloud-API, Wiederherstellung und Supportzugriff können unterschiedliche Mechanismen verwenden.

5. Vertrauliche Daten und Vertrauensgrenzen

Zeichnen Sie das Produkt als Datenfluss. Kennzeichnen Sie Desktop-Manager, Browserprozesse, lokalen Dienst, Cloud-Steuerungsebene, Synchronisierungsspeicher, Updater, Absturzmelder, Supportwerkzeuge und Integrationen Dritter. Fragen Sie an jeder Grenze, was sie weshalb überschreitet.

• □ Welche Profilinhalte bleiben standardmäßig lokal?
• □ Welche Metadaten und vertraulichen Inhalte werden bei aktivierter Synchronisierung hochgeladen?
• □ Wo findet Verschlüsselung statt, und welche Parteien können Entschlüsselungsschlüssel erhalten?
• □ Wie werden lokale Schlüssel geschützt, gesichert, rotiert und wiederhergestellt?
• □ Was können Organisationsadministratoren, Anbietersupport, Infrastrukturbetreiber und Automatisierungsclients lesen?
• □ Sind Cookies, Passwörter, Proxy-Zugangsdaten, Zwei-Faktor-Geheimnisse und Verschlüsselungsschlüssel aus gewöhnlicher Oberfläche, Protokollen, Telemetrie, APIs und Agentenausgaben ausgeschlossen?
• □ Sind Absturzberichte und Diagnosen vorab einsehbar, geschwärzt, einwilligungsbewusst und zeitlich begrenzt aufbewahrt?
• □ Kann der Support arbeiten, ohne ungeschützte Profilarchive oder Zugangsdaten anzufordern?
• □ Werden importierte Erweiterungen, Archive, Browserdownloads und Updatemetadaten als nicht vertrauenswürdig behandelt?
• □ Ist die Löschung über lokale Kopien, Cloud-Objekte, Sicherungen, Protokolle und Supportartefakte hinweg definiert?

Akzeptieren Sie „verschlüsselt“ nicht als vollständige Antwort. Dokumentieren Sie Datenkategorie, Ort, Verschlüsselungsgrenze, Schlüsselinhaber, Wiederherstellungsweg und die Fälle, in denen Klartext vorliegt.

6. Zusammenarbeit und Auditierbarkeit

• □ Bleibt die Zuständigkeit für Profile während Zuweisung und Übergabe eindeutig?
• □ Kann das Produkt gleichzeitige Änderungen verhindern oder sichtbar auflösen?
• □ Werden Einladungen, Rollenänderungen, Starts, Stopps, Freigaben, Exporte, Löschungen, Automatisierungsaufrufe und Wiederherstellungsaktionen protokolliert?
• □ Benennt jedes Ereignis menschliche Akteure, delegierte Arbeitslast, Ressource, Zeit, Entscheidung und Ergebnis?
• □ Werden Vorher- und Nachherwerte wesentlicher Konfigurationsänderungen mit geschwärzten Geheimnissen dokumentiert?
• □ Sind Uhren, Zeitzonen, Ereignisreihenfolge und Anfragekennungen eindeutig?
• □ Sind Auditzugriff, Exportformat, Aufbewahrung und Löschkontrollen dokumentiert?
• □ Kann ein Administrator dieselben Datensätze ändern oder löschen, mit denen seine Handlungen geprüft werden?
• □ Kann Ihr Team Protokolle in sein Überwachungs- oder Untersuchungssystem exportieren?
• □ Wird die Protokollierung fortgesetzt, sicher gepuffert oder sicher abgebrochen, wenn das Auditziel nicht verfügbar ist?

Die Protokollierungsempfehlungen von OWASP empfehlen, Autorisierungsfehler und Aktionen mit höherem Risiko zu dokumentieren, „wann, wo, wer und was“ zu erfassen, den Protokollzugriff zu kontrollieren und technische Geheimnisse zu vermeiden. Wenden Sie diese Prüfung auf die tatsächlich exportierten Ereignisse des Produkts an, nicht nur auf Screenshots einer Sicherheitsseite.

7. Wiederherstellung, Unterbrechung und Ausstieg

Eine Sicherungsaussage ist unvollständig, bis die Wiederherstellung getestet wurde. Das NIST Cybersecurity Framework 2.0 enthält Ergebnisse für das Erstellen, Schützen, Pflegen und Testen von Sicherungen sowie das Prüfen von Wiederherstellungsobjekten und wiederhergestellten Systemen.

• □ Kann unter Beachtung der Profilsperren eine konsistente Sicherung erstellt werden?
• □ Sind lokale und synchronisierte Versionen identifizierbar und geordnet?
• □ Kann eine bedienende Person eine ausgewählte Version wiederherstellen, ohne die aktuelle Kopie zu zerstören?
• □ Werden wiederhergestellte Daten und Browserkompatibilität geprüft, bevor die normale Nutzung fortgesetzt wird?
• □ Was geschieht nach einem beendeten Browserprozess, Netzwerkverlust, vollen Datenträger, unterbrochenen Upload oder Anwendungsabsturz?
• □ Ist die letzte bekanntermaßen intakte Version vor einer fehlgeschlagenen Reparatur geschützt?
• □ Kann ein widerrufenes oder verlorenes Gerät entfernt werden, ohne den einzigen Wiederherstellungsweg zu verlieren?
• □ Sind Wiederherstellungsschlüssel oder -codes sowohl vor beiläufigem Verlust als auch vor uneingeschränktem Administratorzugriff geschützt?
• □ Kann das Team seine Daten in einem dokumentierten Format exportieren und den Export vor Kündigung des Dienstes prüfen?
• □ Gibt es einen unterstützten Lösch- und Kontoschließungsprozess mit einer eindeutigen Erklärung zu verbleibender Aufbewahrung?

Führen Sie Wiederherstellungstests nur mit ersetzbaren Testdaten aus, sofern der Anbieter und Ihr Änderungsprozess produktive Übungen nicht ausdrücklich unterstützen. Dokumentieren Sie Wiederherstellungszeit, verlorenen Zustand, manuelle Schritte, Warnungen und Produktversion. Eine erfolgreiche Demonstration an einem kleinen Profil belegt weder Leistung noch Integrität in Ihrem Produktivmaßstab.

8. Automatisierungs- und Entwicklerkontrollen

• □ Stellt das Produkt versionierte Domänenvorgänge statt uneingeschränktem Datei- oder Prozesszugriff bereit?
• □ Sind Funktionen von API, CLI, SDK, Playwright, CDP, WebDriver, Webhook und Agenten getrennt dokumentiert?
• □ Gibt es eine genaue Kompatibilitätsmatrix für Browser und Client?
• □ Lassen sich Zugangsdaten nach Mandant, Profil, Vorgang, Zielgruppe, Ablauf, Rate und Kosten beschränken?
• □ Erfordern destruktive, massenhafte, extern sichtbare, geheimnistragende oder kostenverursachende Aktionen strengere Richtlinien oder Freigaben?
• □ Sind Vorschauen an genau die Anfrage gebunden, die ausgeführt wird?
• □ Sind verändernde Befehle idempotent oder machen unbekannte Ergebnisse ausdrücklich kenntlich?
• □ Können lange Vorgänge abgebrochen und sicher fortgesetzt werden?
• □ Wird ein Widerruf während eines aktiven Auftrags wirksam?
• □ Sind Automatisierungsentscheidungen im selben Auditverlauf wie menschliche Aktionen zuordenbar?
• □ Können gewöhnliche Automatisierungsausgaben nützlich bleiben, ohne ungeschützten Sitzungszustand zurückzugeben?
• □ Sind Fehlermeldungen spezifisch genug für die Wiederherstellung, ohne Geheimnisse offenzulegen?

Testen Sie Ablehnungspfade. Ein Nur-Lese-Token sollte ein Profil nicht starten können. Ein profilbezogener Token sollte bei einem anderen Ordner scheitern. Abgelaufene Zugangsdaten dürfen nicht unbemerkt zu breiterem Zugriff aktualisiert werden. Ein Agent darf einen abgelehnten Aufruf nicht durch Umschreiben der Anfrage in eine Administratorfreigabe verwandeln können.

9. Bedienerfahrung und Barrierefreiheit

• □ Können Tastaturnutzende jedes Steuerelement, Dialogfeld, jede Tabelle, jedes Menü und jede Profilaktion erreichen, bedienen und verlassen?
• □ Ist der Fokus nach Navigation, Fehlern und modalen Änderungen sichtbar und logisch geordnet?
• □ Funktionieren Beschriftungen, Fehler, Statusänderungen und destruktive Bestätigungen mit Screenreadern?
• □ Bleibt die Oberfläche bei Zoom und vergrößerter Schrift nutzbar?
• □ Sind Farben, Bewegung und Zeitbegrenzungen anpassbar oder nicht wesentlich?
• □ Können Bedienpersonen ausgewählte Organisation, Profil, Proxy, Umgebung und Risikostatus unterscheiden, ohne sich nur auf Farben zu verlassen?
• □ Sind Massenaktionen prüfbar, ohne Nutzende durch unzugängliche dichte Tabellen zu zwingen?
• □ Funktionieren natives Plattformverhalten, Benachrichtigungen, Dateiauswahl, Zugangsdatenabfragen und Updatedialoge konsistent?

WCAG 2.2 bietet testbare Kriterien für Webinhalte, darunter Tastaturbedienung, Fokusreihenfolge, Fokussichtbarkeit, Zielgröße, Fehlererkennung und barrierefreie Authentifizierung. Ein Desktop-Produkt kann native und webbasierte Oberflächen enthalten; kombinieren Sie deshalb relevante Standardprüfungen mit Tests unterstützender Technologien auf jedem unterstützten Betriebssystem.

10. Kommerzielle und betriebliche Eignung

• □ Sind Plätze, gespeicherte Profile, synchronisierte Profile, Speicher, Datenverkehr, gleichzeitige Sitzungen, API-Rate, Automatisierungsworker und Supportstufen getrennt und eindeutig bepreist?
• □ Welche Grenzen sind harte Stopps, Mehrverbrauch oder Fair-Use-Regeln?
• □ Können Abrechnungs- oder Kapazitätsänderungen ohne Freigabe eines Administrators erfolgen?
• □ Sind unterstützte Proxy-Protokolle, Authentifizierungsmethoden, Erweiterungen und Netzwerkumgebungen dokumentiert?
• □ Deckt die Supportrichtlinie Vorfälle mit Browserupdates, Profilbeschädigung, fehlgeschlagener Wiederherstellung, Sicherheitsmeldungen und Kontowiederherstellung ab?
• □ Sind Dienststatus, Vorfallkommunikation und Eskalationswege real und überwacht?
• □ Definiert der Vertrag Datenrückgabe, Löschung, Preisänderungen, Sperrung und Beendigung?
• □ Können Sie aussteigen, ohne die zum Nachweis einer sicheren Migration benötigten Belege zu verlieren?

Berechnen Sie die Kosten anhand maximaler gleichzeitiger Arbeit, erwartetem synchronisierten Zustand, Automatisierungsvolumen und Supportbedarf. Dokumentieren Sie Steuern, Jahresbindungen, Mehrverbrauch und Migrationsarbeit. Vergleichen Sie nicht nur die größte Profilzahl auf den Preisseiten.

Plan für einen kontrollierten Test

Verwenden Sie Testkonten, synthetische Zugangsdaten und eigens für die Bewertung angelegte Profile. Importieren Sie keine produktiven Cookies, nur um den Test realistischer erscheinen zu lassen.

1. Umgebung dokumentieren. Halten Sie Anwendungs- und Browserversionen, Betriebssystem, Hardware, Netzwerk, Proxytyp, Erweiterungssatz, Kontotarif und Testdatum fest.
2. Zwei Rollen und mehrere Profile anlegen. Beziehen Sie einen Administrator, eine eingeschränkte Bedienperson, getrennte Ordner und mindestens ein Profil ein, auf das die Bedienperson nicht zugreifen darf.
3. Normalen Arbeitsablauf ausführen. Starten, nutzen, stoppen, übergeben und erneut starten. Dokumentieren Sie erwarteten und tatsächlichen Zustand.
4. Ablehnung prüfen. Versuchen Sie mit der eingeschränkten Identität ein Profil außerhalb des Umfangs, einen Export, eine Rollenänderung und einen Automatisierungsbefehl.
5. Unterbrechung prüfen. Unterbrechen Sie mit ersetzbaren Daten einen Browserstopp oder Synchronisierungsschritt über eine vom Anbieter unterstützte oder anderweitig sichere Methode. Prüfen Sie den Wiederherstellungsweg.
6. Wiederherstellen und vergleichen. Stellen Sie einen bekannten Snapshot in einer neuen Kopie wieder her, prüfen Sie seine Integrität und bewahren Sie die aktuelle Kopie bis zur Abnahme auf.
7. Zugriff widerrufen. Entfernen Sie Benutzer, Gerät, Sitzung und Dienstzugangsdaten; bestätigen Sie die Ablehnung in Oberfläche und API und prüfen Sie die Auditereignisse.
8. Portabilität prüfen. Exportieren Sie die erlaubten Daten, prüfen Sie das dokumentierte Format, importieren Sie sie, sofern unterstützt, in ein ersetzbares Ziel und ermitteln Sie ausgelassene Daten.
9. Barrierefreiheit prüfen. Führen Sie Kernaufgaben mit Tastatur und relevanten unterstützenden Technologien auf jeder benötigten Plattform aus.
10. Kosten und Aussagen abgleichen. Vergleichen Sie beobachteten Ressourcenverbrauch und Supportantworten mit Angebot und Vertrag.

Vorlage für den Entscheidungsdatensatz

Anforderung	Priorität	Ergebnis	Nachweis und Datum	Einschränkung oder Risiko	Verantwortliche Person und nächster Schritt
Beispiel: Bedienperson kann Sitzungszustand nicht exportieren	Freigabekriterium	Bestanden	Kontrollierter Test, Version X, JJJJ-MM-TT	Nur API-Oberfläche; CLI nicht getestet	Sicherheitsverantwortliche Person testet CLI

Schließen Sie die Bewertung mit vier ausdrücklichen Listen ab:

• Freigabekriterien, die mit ausreichendem Nachweis bestanden wurden;
• Bedenken, die eine benannte verantwortliche Person bis zu einem festgelegten Prüfdatum akzeptiert hat;
• Punkte, die nicht geprüft bleiben;
• Bedingungen für eine Neubewertung, etwa neue Browser-Engine, neuer Identitätsanbieter, Updater, Preismodell oder Profilformat.

Häufige Warnsignale

Unterbrechen Sie die Entscheidung, wenn:

• die Browserversion nicht ermittelt werden kann;
• die Sandbox für normale Nutzung deaktiviert werden muss;
• Administratoren und Automatisierung dauerhaft dieselben Zugangsdaten verwenden;
• das Produkt bei Teamübergaben auf ungeschützte Cookies oder gemeinsam genutzte Passwörter angewiesen ist;
• eine API Geheimnisse exportieren kann, die laut Oberfläche geschützt sind;
• Auditereignisse den Akteur auslassen oder nicht exportierbar sind;
• „Sicherung“ nur bedeutet, dass eine Cloud-Kopie existiert, ohne nachgewiesene Wiederherstellung;
• der Anbieter unterbrochene Schreibvorgänge oder gleichzeitigen Profilzugriff nicht erklären kann;
• für einen unzugänglichen kritischen Arbeitsablauf keine Alternative existiert;
• eine Sicherheitsmeldung das Versenden von Geheimnissen per gewöhnlicher E-Mail erfordert; oder
• Produktaussagen Unsichtbarkeit, garantierten Kontozugriff oder die Umgehung von Plattformdurchsetzung versprechen.

Ein Ergebnis „Nicht geprüft“ ist keine Anschuldigung. Es ist eine präzise Aussage über fehlende Nachweise. Halten Sie es sichtbar, bis der Anbieter Belege liefert, Ihr Team das Verhalten testet oder die entscheidungsverantwortliche Person das Risiko akzeptiert.