Drittanbieter-Risikoassessment: Vorlage und Praxisleitfaden für jährliche Lieferanten-Audits

Ein Drittanbieter-Risikoassessment ist mehr als eine jährliche Fragebogen-Routine. In der Praxis entscheidet es darüber, ob Ihr Unternehmen im laufenden Betrieb Zugriff, Datenflüsse und Abhängigkeiten von Dienstleistern kontrolliert – oder ob Risiken erst sichtbar werden, wenn etwas schiefgeht: Security Incident, Ausfall einer Plattform, unklare Subunternehmerkette oder fehlende Nachweise im Audit. Gerade für IT-Leitung, Compliance und Geschäftsführung ist der jährliche Lieferanten-Audit deshalb kein „Papierprozess“, sondern ein Steuerungsinstrument: Welche Partner sind kritisch, welche Kontrollen sind zwingend, wo reicht Monitoring, und wo brauchen Sie Vertrags- und Technikmaßnahmen?

Dieser Praxisleitfaden zeigt, wie Sie ein Drittanbieter-Risikoassessment so aufsetzen, dass es auditfähig, priorisiert und operativ nutzbar ist. Sie erhalten eine praxistaugliche Vorlage als Struktur (Kontrollbereiche, Fragen, Nachweise, Bewertung, Maßnahmenplan) sowie Hinweise, wie Sie den Prozess mit Rollen, Evidenzen und Eskalationen im Alltag verankern – ohne die Organisation mit Vollprüfungen zu überlasten.

Warum jährliche Lieferanten-Audits in der IT oft scheitern

Viele Organisationen starten mit einem generischen Fragebogen. Nach zwei Jahren sind alle „grün“, obwohl sich Technologien, Datenkategorien und Betriebsmodelle permanent ändern. Die typischen Ursachen:

• Kein klares Scoping: Es wird „der Lieferant“ geprüft, nicht die konkrete Leistung. Ein Anbieter kann gleichzeitig unkritische Beratung und hochkritisches Hosting liefern – das Risikoprofil ist pro Leistung unterschiedlich.
• Unklare Nachweise: Antworten ohne Evidenz (z. B. „Wir haben ein ISMS“) sind im Audit wertlos und helfen der IT operativ nicht.
• Keine risikobasierte Priorisierung: Gleichbehandlung aller Dienstleister führt zu zu viel Aufwand bei Low-Risk und zu wenig Tiefe bei High-Risk.
• Maßnahmen enden im Tracker: Findings werden dokumentiert, aber nicht in Verträge, Betriebsprozesse oder technische Kontrollen überführt.
• Fehlende Ownership: Vendor Management, IT-Security, Datenschutz, Einkauf und Fachbereich arbeiten parallel statt entlang eines gemeinsamen Kontrollmodells.

Ein belastbares Drittanbieter-Risikoassessment löst diese Punkte durch zwei Prinzipien: erstens eine leistungsbezogene Risikobetrachtung (was wird tatsächlich betrieben/geliefert?), zweitens eine evidence-basierte Prüfung (welche Nachweise belegen die Aussagen?).

Regulatorischer und auditiver Kontext: Welche Anforderungen Sie praktisch abdecken müssen

Je nach Branche und Prüfregime unterscheiden sich die Formulierungen, die Erwartung ist jedoch ähnlich: Risiken aus ausgelagerten IT-Leistungen müssen identifiziert, bewertet, gesteuert und überwacht werden. Typische Bezugspunkte in der Praxis:

• DSGVO / Auftragsverarbeitung: Wenn personenbezogene Daten verarbeitet werden, brauchen Sie klare Rollen (Verantwortlicher/Auftragsverarbeiter), Verträge (AVV), Subunternehmerregelungen, TOMs (technische und organisatorische Maßnahmen) und Nachweisführung.
• ISMS nach ISO 27001: Lieferantenbeziehungen, Zugriffskontrollen, Incident-Management, Business Continuity und Change-Management müssen auch bei Dritten kontrolliert werden. Wichtig ist die Nachvollziehbarkeit: Risk Treatment, Kontrollen, Reviews.
• SOC 2, ISO-Atteste, TISAX: Solche Berichte sind hilfreiche Evidenzen, ersetzen aber keine eigene Risikoeinschätzung. Entscheidend sind Scope, Gültigkeit, Ausnahmen und Abweichungen.
• Finanz-/KRITIS-nahe Anforderungen: Oft wird eine strengere Dokumentation erwartet (kritische Auslagerungen, Exit-Fähigkeit, Testnachweise, strengere Subunternehmersteuerung). Auch ohne formale Pflicht lohnt sich das Vorgehen für kritische IT-Abhängigkeiten.

Für die jährlichen Lieferanten-Audits bedeutet das: Sie sollten nicht „Normen abprüfen“, sondern prüffähige Kontrollen etablieren, die in mehreren Regimen verwendbar sind (Security, Datenschutz, Resilienz, Betrieb). So reduzieren Sie Doppelarbeit.

Schritt 1: Scope definieren – vom „Lieferanten“ zur konkreten Leistung

Startpunkt ist ein Leistungs- und Datenbild pro Anbieter. Ohne diese Grundlage werden Bewertungen beliebig. Eine praxistaugliche Scoping-Logik beantwortet drei Fragen:

• Was liefert der Drittanbieter konkret? SaaS, Hosting, Managed Service, Support, Entwicklung, Betrieb von Integrationen, Zugriff auf interne Systeme etc.
• Welche Daten und Systeme sind betroffen? Datenklassifizierung (öffentlich, intern, vertraulich, besonders schützenswert), personenbezogene Daten, geschäftskritische Daten, Geheimhaltungsstufen.
• Welche Betriebsabhängigkeit entsteht? RTO/RPO (Wiederanlauf-/Datenverlustziele), Single Point of Failure, Integrationstiefe, Authentisierung (SSO), Schlüssel-/Zertifikatsabhängigkeit, Netzwerkpfade.

Wichtig: Dokumentieren Sie das Scope so, dass es in sechs Monaten noch stimmt. Das gelingt, wenn Sie es an Artefakte koppeln: Vertrag/Leistungsbeschreibung, Architekturübersicht, Datenfluss, Schnittstellenliste, Liste privilegierter Zugänge, und für Cloud/SaaS: Tenant- und Admin-Konzepte.

Mini-Vorlage: Scope-Faktenblatt pro Leistung

Nutzen Sie pro geprüfter Leistung ein einseitiges Faktenblatt (nicht pro Lieferant als Ganzes):

• Service/Produkt, verantwortlicher Fachbereich, Service Owner in der IT
• Betriebsmodell (SaaS/PaaS/IaaS/Managed Service/On-Prem beim Anbieter)
• Datenkategorien inkl. personenbezogen ja/nein, Datenstandorte/Region
• Integrationen (APIs, VPN, SFTP, Event-Streams), Authentisierung (SSO/MFA), Berechtigungsmodell
• Kritikalität für Geschäftsprozesse, RTO/RPO-Ziele, Abhängigkeiten
• Subunternehmer-/Unterauftragskette relevant ja/nein
• Vertragsartefakte (AVV, SLA, DPA, Sicherheitsanhänge), Laufzeit/Kündigungsfristen

Schritt 2: Risikobasierte Priorisierung – welche Lieferanten jährlich tief geprüft werden

„Jährlich alle gleich tief“ ist selten leistbar. Bewährt hat sich eine 3-stufige Einteilung (High/Medium/Low) auf Basis von Impact und Exposure:

• Impact (Auswirkung): Geschäftsprozessstillstand, Rechts-/Compliance-Folgen, Datenverlust/Integrität, Umsatz-/Reputationsschaden. Hier helfen RTO/RPO und Datenklassifizierung als objektive Anker.
• Exposure (Angriffs-/Fehlerfläche): Internet-exponierte Dienste, privilegierte Zugänge, tiefe Integration, Zugriff auf Identitäten (SSO/IdP), Verarbeitung besonderer Datenkategorien, Subunternehmerkette, häufige Changes.

Ergebnis ist eine Audit-Tiefe: High-Risk mit Nachweisen, Interview, ggf. Vor-Ort/Remote-Assessment; Medium mit Nachweisen und Stichproben; Low mit Self-Assessment plus Monitoring (z. B. Vertragsreview bei Änderungen, Security-Alerts, Re-Zertifikate).

Bewertungslogik als Scorecard (ohne Scheingenauigkeit)

Vermeiden Sie 1–100-Punkteskalen, die Genauigkeit suggerieren. Nutzen Sie wenige Kriterien mit klarer Bedeutung, z. B. 0/1/2 je Kriterium, und definieren Sie Schwellenwerte. Wichtig ist, dass die Organisation versteht, warum ein Anbieter High-Risk ist – und welche Maßnahmen daraus folgen.

Schritt 3: Die Drittanbieter-Risikoassessment-Vorlage – Kontrollbereiche, Fragen, Nachweise

Die folgende Vorlage ist so strukturiert, dass Sie sie als Audit-Fragebogen, Interviewleitfaden und Evidence-Check nutzen können. Entscheidend ist die Spalte „Nachweis“: Ohne definierte Evidence bleibt die Prüfung weich.

A. Governance, Verantwortlichkeiten, Subunternehmer

• Rollenmodell: Wer ist beim Anbieter für Security, Datenschutz, Betrieb verantwortlich? Nachweis: Organigramm/Responsibility Matrix, Kontaktwege für Incidents.
• Subunternehmersteuerung: Welche Unterauftragnehmer werden eingesetzt, wofür, in welchen Regionen? Nachweis: aktuelle Subprocessor-Liste, Änderungsprozess, Widerspruchs-/Informationsmechanismus.
• Change-Transparenz: Wie werden wesentliche Änderungen an Service, Standorten, Sicherheitskontrollen angekündigt? Nachweis: Policy/Prozess, Beispielkommunikation.

B. Informationssicherheit: technische Basiskontrollen

• Identitäts- und Zugriffskontrolle: MFA für Admins, RBAC (rollenbasiertes Berechtigungsmodell), Joiner/Mover/Leaver-Prozess. Nachweis: IAM-Policy, Screenshots sind möglich, besser: kontrollierte Auszüge/Audit-Logs.
• Verschlüsselung: In Transit (TLS), at Rest (Speicher/DB), Schlüsselmanagement (KMS/HSM). Nachweis: Architektur-/Security-Konzept, KMS-Prozess, Zertifikats-/Key-Rotation.
• Vulnerability Management: Patchzyklen, kritische Schwachstellen, Abhängigkeiten. Nachweis: Policy, exemplarischer Patch-Report, CVE-Handling, Pen-Test-Zusammenfassung (ohne sensible Details).
• Logging und Monitoring: Sicherheitsrelevante Logs, Aufbewahrung, Alarmierung, Integrationsmöglichkeit in SIEM. Nachweis: Log-Policy, Event-Kategorien, Retention-Nachweis.

C. Datenschutz und Datenhoheit

• Rechtsgrundlage/AVV: Vertragliche Regelung, TOM-Anhang, Audit-/Nachweisklauseln. Nachweis: unterzeichnete Dokumente, Versionierung.
• Datenstandort und Datenflüsse: Regionen, Backups, Replikation, Supportzugriffe. Nachweis: Data Processing Diagramm, Standortliste, Supportprozess.
• Betroffenenrechte und Löschung: Export, Löschfristen, „Deletion by Design“. Nachweis: Prozessbeschreibung, Testnachweis/Stichprobe.

D. Betrieb, Resilienz, Incident-Management

• BCM/DR: Backup, Wiederherstellung, getestete Verfahren, Abhängigkeiten. Nachweis: DR-Konzept, Testprotokolle, RTO/RPO-Fähigkeit.
• Incident-Management: Klassifikation, Meldefristen, Root-Cause-Analysen (RCA), Lessons Learned. Nachweis: Prozess, Beispielbericht (anonymisiert), Kommunikationswege.
• SLA/SLM: Verfügbarkeit, Supportzeiten, Reaktionszeiten, Wartungsfenster. Nachweis: SLA, Monatsreports, Eskalationsmatrix.

E. Schnittstellen, Integration, Zugriffspfade

• API-/Integration-Sicherheit: Authentisierung, Token-Laufzeiten, IP-Restriktionen, Rate Limits. Nachweis: technische Doku, Konfigurationsauszüge, Security-Controls.
• Privileged Access: Administrative Zugriffe des Anbieters auf Ihre Umgebung (Support, Remote-Hands). Nachweis: Verfahren, Genehmigungen, Protokollierung, Zeitbegrenzung.
• Mandantentrennung (Multi-Tenant): Isolation, Datenzugriff, Testdaten. Nachweis: Architektur-/Kontrollbeschreibung, Audit-Berichtauszug.

F. Exit-Fähigkeit und Lock-in-Risiko

• Datenrückgabe: Formate, Vollständigkeit, Fristen, Kosten. Nachweis: Exit-Klausel, Exportverfahren, Testexport.
• Übergabeprozesse: Dokumentation, Admin-Übergabe, Schlüssel/Secrets, Schnittstellen. Nachweis: Runbooks, Asset-Liste.
• Business Continuity bei Anbieter-Ausfall: Alternativen, Übergangsmodus, Notbetrieb. Nachweis: Szenarienplan, Abhängigkeiten.

Schritt 4: Evidence-Standards – was im Audit wirklich zählt

Ein häufiger Streitpunkt: „Der Anbieter hat doch bestätigt…“. Audits verlangen Nachvollziehbarkeit. Legen Sie deshalb Evidenzklassen fest:

• Klasse 1 (stark): unabhängige Prüfberichte mit passendem Scope (z. B. SOC 2 Type II, ISO 27001 Zertifikat inkl. Geltungsbereich), Testprotokolle, Audit-Logs, Verträge, Policy-Versionen.
• Klasse 2 (mittel): interne Reports, Prozessbeschreibungen, Ticket-Auszüge, Change-Historien, anonymisierte RCA-Berichte.
• Klasse 3 (schwach): Selbstauskünfte ohne Nachweis, Marketingunterlagen, generische Whitepaper.

Definieren Sie je Risikoklasse, welche Evidenz mindestens erforderlich ist. Bei High-Risk sollten Kernkontrollen (Zugriff, Logging, Incident, DR, Subunternehmer, Datenschutz) mindestens Klasse 1 oder belastbare Klasse 2 sein. Wo das nicht möglich ist, entsteht automatisch ein Finding mit Maßnahmenplan.

Schritt 5: Bewertung und Maßnahmenplan – vom Finding zur umsetzbaren Entscheidung

Ein jährliches Lieferanten-Audit ist nur dann wirksam, wenn es zu Entscheidungen führt: akzeptieren, mitigieren, übertragen (z. B. Versicherung/Vertrag) oder beenden. Dafür brauchen Sie eine klare Finding-Struktur:

• Finding: Was ist die Abweichung? (z. B. „MFA für administrative Zugänge nicht verpflichtend“)
• Risikoauswirkung: Welche Szenarien werden wahrscheinlicher? (Account Takeover, Datenabfluss, Manipulation)
• Betroffener Scope: Welche Leistung, welche Daten, welche Integrationen?
• Priorität: High/Medium/Low, begründet über Impact/Exposure
• Empfohlene Maßnahme: technisch, vertraglich, prozessual
• Owner und Frist: Wer treibt es (Anbieter, internes Team, Einkauf), bis wann?
• Akzeptanzkriterium: Woran erkennen wir, dass es erledigt ist? (konkreter Nachweis)

Risikobehandlung ohne Illusionen: „Accept“ ist legitim, aber dokumentationspflichtig

Nicht jedes Risiko lässt sich wirtschaftlich eliminieren. Wenn Sie ein Risiko akzeptieren, muss klar sein: Wer genehmigt die Akzeptanz (Mandat), auf welcher Grundlage (Risikobild), für welchen Zeitraum (Review-Datum) und mit welchen Kompensationskontrollen (z. B. strengere eigene Überwachung, geringere Datenfreigaben, zusätzliche Backups, Vertragsergänzung bei nächster Verlängerung).

Schritt 6: Governance im Alltag – Rollen, Taktung, Eskalationen

Für „Gestione fornitori“ zählt Umsetzbarkeit: Der Prozess muss mit Einkauf, IT-Betrieb und Compliance funktionieren. Eine bewährte Rollenverteilung:

• Service Owner (intern): fachliche Kritikalität, Nutzung, Changes, Budget; initiiert Re-Assessment bei Änderungen.
• IT-Security: Sicherheitskontrollen, Evidence-Review, Findings, technische Maßnahmen.
• Datenschutz: AVV, Datenflüsse, Betroffenenrechte, Subunternehmer, Transfermechanismen.
• Einkauf/Vendor Management: Vertragsklauseln, SLA, Eskalationen, Renewal-Termine, Subunternehmerklauseln.
• IT-Betrieb: Integration, Monitoring, Backup/Restore, Notfallrunbooks, Zugriffsprozesse.
• Risikomanagement/Management: Risikoakzeptanz, Priorisierung, Reporting.

Taktung: Für High-Risk mindestens jährlich, zusätzlich anlassbezogen (z. B. neue Datenkategorie, neue Region, größere Architekturänderung, schwerer Incident, Wechsel wesentlicher Subunternehmer). Medium typischerweise jährlich/light, Low alle 24 Monate plus Trigger.

Eskalationslogik: Welche Ereignisse ein Sofort-Review auslösen sollten

• Security Incident mit möglichem Datenbezug oder privilegiertem Zugriff
• Wechsel von Subunternehmern, Rechenzentrumsregionen oder Supportmodellen
• Neue Integrationen (z. B. SSO-Anbindung, API-Schreibzugriff, Netzwerk-Tunnel)
• Vertragsverlängerung/Preisänderung mit Einfluss auf SLA oder Exit
• Wesentliche Produktänderungen (Multi-Tenant-Architektur, neue Datenverarbeitung)

Checkliste: Jahres-Audit als wiederholbarer Ablauf (Ende-zu-Ende)

Die folgende Checkliste ist so formuliert, dass Sie sie in ein Ticket-System oder ein Audit-Board übertragen können:

1. Lieferantenliste aktualisieren: aktive Leistungen, Scope-Faktenblatt, Renewal-Daten, Owner.
2. Klassifizieren: Impact/Exposure bewerten, High/Medium/Low festlegen, Prüfplan ableiten.
3. Dokumente anfordern: definierte Evidence je Kontrollbereich, Fristen, sichere Übermittlung.
4. Vorprüfung: Scope der Nachweise prüfen (Gültigkeit, Zeitraum, Ausnahmen), Lücken markieren.
5. Interview/Workshop: offene Punkte, Betrieb/Incident/DR, Subunternehmer, Zugriffspfade.
6. Technik-Stichprobe (wo möglich): Log- und Zugriffsnachweise, Export-/Löschtest, SLA-Reports.
7. Findings und Risiken formulieren: mit Owner, Fristen, Akzeptanzkriterien.
8. Management-Entscheid: akzeptieren/mitigieren/übertragen/beenden, dokumentieren.
9. Nachverfolgung: Maßnahmenstatus, Evidence-Abnahme, Re-Audit bei Überzug.
10. Lessons Learned: Katalog anpassen, Trigger definieren, nächste Runde planen.

Praxis: Technische Prüfspuren, die Sie ohne „Deep Dive“ nutzen können

Auch ohne Quellcode oder interne Tool-Details können Sie als Kunde sinnvolle, prüffähige Spuren einfordern oder selbst erzeugen. Drei Beispiele, die in vielen Umgebungen funktionieren:

1) Zugriff und privilegierte Aktionen: Audit-Log-Auszüge definieren

Vereinbaren Sie, dass der Anbieter auf Anfrage Audit-Log-Auszüge für definierte Ereignisse liefert (z. B. Admin-Login, Berechtigungsänderungen, Datenexport, Supportzugriffe). Wichtig: Zeitraum, Mandant, Identität, Ergebnis, Quelle (IP/Device soweit zulässig), und eine Integritätszusicherung.

Beispiel: Mindestanforderungen an einen Audit-Log-Auszug (inhaltlich)
- Zeitraum (Start/Ende) und Zeitzone
- Mandant/Umgebung/Account-ID
- Ereignistyp (Admin-Login, Role-Change, Export, API-Token-Create, Support-Access)
- Subjekt (User/Service-Account), inkl. eindeutiger ID
- Ergebnis (success/fail) und Fehlergrund
- Quelle (IP/Netzsegment, ggf. Device/Client-Kennung)
- Korrelations-ID/Request-ID (für Incident-Nachverfolgung)
- Nachweis der Unveränderbarkeit (z. B. Signatur/Hash-Kette oder Systembeschreibung)

2) Backup- und Restore-Fähigkeit: Testnachweis statt Versprechen

Für kritische Leistungen ist nicht nur „Backup vorhanden“ relevant, sondern „Restore getestet“. Fordern Sie mindestens einen anonymisierten Restore-Testnachweis pro Jahr oder pro wesentlicher Änderung an. Wenn der Anbieter keinen Test liefert, dokumentieren Sie das als Risiko und setzen Kompensationen (z. B. eigener Datenexport, zusätzliche Offline-Backups, kleinere Datenhaltung).

3) Datenlöschung und Datenexport: Stichprobe mit Akzeptanzkriterien

Gerade bei SaaS ist Löschung oft unklar (Produktivdaten, Backups, Logs). Definieren Sie Akzeptanzkriterien: Welche Datenobjekte müssen exportierbar sein, welche Löschfristen gelten, wie wird der Abschluss nachgewiesen. Das ist sowohl Datenschutz- als auch Exit-relevant.

Kosten und Aufwand realistisch planen: Was „jährlich prüfen“ in der Organisation bedeutet

Die größte Fehleinschätzung ist, dass ein Lieferanten-Audit nur aus dem Versand eines Fragebogens besteht. Planen Sie bewusst Kapazität für drei Arbeitspakete ein:

• Vorbereitung: Scope aktualisieren, Klassifizierung, Evidence-Anforderung, Terminierung. Das ist oft der größte Hebel für Qualität.
• Durchführung: Evidence-Review, Interview, Findings. Hier ist methodische Konsistenz wichtiger als maximale Tiefe.
• Nacharbeit: Maßnahmen, Vertragsänderungen, technische Kompensationen, Nachverfolgung. Ohne Nacharbeit bleibt das Assessment wirkungslos.

Für Entscheider ist relevant: Ein schlanker, risikobasierter Prozess reduziert langfristig Kosten, weil er ungeplante Eskalationen, Vertragsnachverhandlungen unter Zeitdruck und „Not-Projekte“ nach Incidents vermeidet. Gleichzeitig muss die Organisation die Konsequenz akzeptieren: High-Risk-Lieferanten werden nicht nur „bewertet“, sondern aktiv gesteuert.

Audit-Readiness: Wie Sie Ergebnisse so dokumentieren, dass Prüfungen schneller werden

Audit-Readiness bedeutet, dass Sie innerhalb kurzer Zeit zeigen können: Welche Drittanbieter sind relevant, wie wurden sie klassifiziert, welche Kontrollen gelten, welche Nachweise liegen vor, und wie wurden Abweichungen behandelt. Dafür genügt ein kompaktes Set an Artefakten:

• Lieferantenregister mit Leistungs-Scope und Risikoklasse
• Assessment-Protokoll (Datum, Teilnehmer, Scope, Evidence-Liste, Findings)
• Maßnahmenplan mit Status und Abnahme-Evidence
• Risikoakzeptanzen mit Mandat und Review-Datum
• Vertrags-/SLA-/AVV-Versionen und relevante Anhänge

Wenn Sie diese Artefakte konsequent versionieren (z. B. in einem DMS oder GRC-Tool) und die Verantwortung je Leistung klar zuweisen, werden externe Audits und interne Revision deutlich effizienter.

Schlussfazit: Ein gutes Drittanbieter-Risikoassessment ist ein Steuerungsprozess, kein Fragebogen

Jährliche Lieferanten-Audits lohnen sich dann, wenn sie drei Ergebnisse zuverlässig liefern: erstens eine belastbare, leistungsbezogene Risikoklassifizierung; zweitens evidenzbasierte Aussagen zu Kernkontrollen (Zugriff, Incident, Resilienz, Datenschutz, Subunternehmer); drittens einen Maßnahmenplan, der tatsächlich in Betrieb, Verträge und Entscheidungswege übergeht. Damit wird aus „Vendor Management“ eine operative Fähigkeit: weniger Überraschungen, klarere Verantwortlichkeiten und bessere Entscheidungsgrundlagen bei Verlängerungen, Erweiterungen oder Exit-Szenarien.

Wenn Sie als nächsten Schritt angrenzende Themen vertiefen möchten, sind insbesondere SLA-/Vertragsklauseln sowie Exit- und Notfallprüfungen die natürlichen Anschlussstellen für ein konsistentes Dienstleistermanagement.

Für dieses Thema sind auch Third-Party Risk Management und Lieferantenbewertung wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.