Am Deutschen Zentrum für Altersfragen wird folgender Auftrag ausgeschrieben:

Typo3-Update, Barrierefreiheit, Weiterentwicklung und technische Betreuung der Website www.dza.de

Die Ausschreibungsunterlagen bestehen aus:

• Bewerbungs- und Angebotsbedingungen
• Anlage 1: Angebotsvordruck
• Anlage 2: Leistungsbeschreibung
• Anlage 3: Mustervertrag
• Anlage 4: Mustervertrag Auftragsdatenverarbeitung Art. 28 DSGVO
• Anlage 5: Eigenerklärung §31 UVgO
• Anlage 6:  Eigenerklärung §19 Mindestlohngesetz (MiLoG)
• Anlage 7: Erklärung Unterauftragnehmende
• Anlage 8: Bewertungsraster Eignung
• Anlage 9: Bewertungsraster Wirtschaftlichkeit
• Anlage 10: Vordruck Eignungsnachweise

ACHTUNG: Aufgrund zahlreicher Nachfragen, die im Laufe dieser Woche hier beantwortet werden, haben wir die Frist für die postalische Abgabe der Angebote angepasst, damit alle Bieter*innen ausreichend Zeit haben, die zusätzlichen Informationen in ihrem Angebot zu berücksichtigen. Angebote müssen nun bis zum 23.01.2026, 10 Uhr, postalisch eingegangen sein.

Dieses Vergabeverfahren wird ausschließlich postalisch durchgeführt. Angebote können spätestens bis zum 23.01.2026 nur postalisch abgegeben werden, mit der Kennziffer DZA_2026 sowie dem Vermerk „AUSSCHREIBUNG TYPO3/WEBSITE“ an:

Deutsches Zentrum für Altersfragen
Manfred-von-Richthofen-Straße 2
12101 Berlin

Fragen sind bis zum 07.01.2026 12:00 Uhr ausschließlich über die E-Mail-Adresse vergabedzade einzureichen. Die Fragen und Antworten werden allen Bieter*innen in anonymisierter Form hier, auf www.dza.de/ueber-uns/ausschreibung zur Verfügung gestellt.

Fragen und Antworten zur Ausschreibung:

Sind die genannten Typo3-Zertifikate zwingend erforderlich oder kann der Nachweis von Kenntnissen und Erfahrungen bei der Nutzung der Programmiersprache Typo3 auch anderweitig erbracht werden?

Die in der Ausschreibung genannten TYPO3-Zertifikate werden als bevorzugter Qualifikationsnachweis angesehen, da sie aufgrund ihrer Standardisierung einen geringeren Prüfungs- und Bewertungsaufwand gegenüber anderen Nachweisarten ermöglichen.
Gleichwertige fachliche Qualifikationen können jedoch auch durch nachweisbare praktische Erfahrung im TYPO3-Umfeld erbracht werden, insbesondere durch die Entwicklung, Wartung und Veröffentlichung eigener TYPO3-Extensions, etwa im offiziellen TYPO3 Extension Repository (TER) oder über öffentlich zugängliche GitHub-Repositorien.
Ergänzend wird darauf hingewiesen, dass reine Screenshots bisheriger Projekte hierfür nicht ausreichend sind, da sie überwiegend visuelle Arbeitsproben darstellen und keine belastbare Aussage über die technische Umsetzung, Code-Qualität oder die tatsächliche Eigenleistung zulassen.

Falls die Zertifikate obligatorisch sind: Müssen diese von den konkret im Projekt eingesetzten Mitarbeitern gehalten werden oder reicht der Nachweis, dass das Unternehmen über entsprechend zertifizierte Mitarbeiter verfügt?

Die Zertifikate sollten von den eingesetzten Mitarbeiter*innen gehalten werden, bzw. (siehe oben) können die Kenntnisse auch anderweitig nachgewiesen werden.

Wird für die Teilnahme das Zertifikat für den Developer und zusätzlich auch das Zertifikat für den Integrator benötigt - die Kenntnisse des Developers beinhalten (übertreffen) ja diejenigen des Integrators?

Aus unserer Sicht sind die beiden Zertifikate nicht deckungsgleich und daher beide wünschenswert. Allerdings können Kenntnisse auch anderweitig nachgewiesen werden (siehe oben).

Ist es ggf. möglich das Zertifikat zeitnah nachzureichen, falls wir vor dem Abgabetermin keinen Termin für die Prüfung mehr bekommen?

Zertifikate, die nicht bei Angebotsabgabe vorliegen, können nicht mit in die Wertung einfließen. Bitte geben Sie in diesem Fall gleichwertige fachliche Qualifikationen an (siehe oben)

Welche TYPO3-Version wird derzeit eingesetzt?

Die aktuell eingesetzte Typo3-Version lautet 9.5.31

Aktuell kommt ein in die Jahre gekommenes TYPO3 9.5 System zum Einsatz. Gibt es hier aufgrund des Alters ggf. Anpassungen an Core-Dateien, die nicht durch separate Extensions gekapselt sind?

Die Typo3-Dateien sind ohne jegliche Modifikation.

Gehen wir in der Annahme recht, dass das Upgrade/Migrationsangebot auf TYPO3 Version 13.x zu kalkulieren ist, da für TYPO3 12.x absehbar ein eingeschränkter bzw. auslaufender Wartungs-/Supportzeitraum gilt und ein zukunftssicheres Releaseziel erforderlich ist? Da in den Unterlagen eine optionale Versionierung angedeutet wird, bitten wir um Klarstellung zur Vergleichbarkeit der Angebote: Soll der wertungsrelevante Basispreis auf TYPO3 13.x (oder 12.x) bezogen werden? Falls 13.x optional bleiben soll: Sollen wir 13.x als Option zusätzlich ausweisen und 12.x als Basis – oder umgekehrt? Wie wird die Zielversion in der Preiswertung berücksichtigt (Basis vs. Option)?[

TYPO3 12 LTS ist als wertungsrelevante Basisversion vorgesehen, da diese derzeit eine breitere Extension-Unterstützung bietet. TYPO3 13 LTS ist optional auszuweisen.

Welche TYPO3-Extensions kommen aktuell zum Einsatz und müssen beim Upgrade berücksichtigt werden?

Die hier verlinkte Liste der Extensions ist noch ohne Angabe, was zu ersetzen ist.

Extensions deren Schlüssel mit DZA_ oder cm_ beginnen (rot markiert) sind Kandidaten für Neu-Programmierung oder Refactoring. Nicht mehr gepflegte Extensions sollen durch gleichwertige, mit der aktuellen LTS Version kompatible, ersetzt werden.

Die System-Extensions bringt Typo3 jeweils mit und sind daher für die Aktualisierung eher nebensächlich.

Können Sie zu den Extensions, deren Schlüssel mit DZA_ oder cm_ beginnt, Informationen zum Funktionsumfang (z.B. Anzahl der Plugins, Controller, Services etc.) geben?

Im System werden sechs projektspezifische Local-Extensions (DZA_*, cm_*) eingesetzt (siehe Überblick). Zwei davon (DZA_lists, DZA_members) sind Extbase-basierte Fach-Extensions mit insgesamt drei Controllern und neun Actions. Die übrigen Extensions stellen Content-Elemente, Layouts und projektspezifische Konfigurationen bereit. Es kommen keine externen Vendor-Extensions, Middleware oder Hintergrundservices zum Einsatz. 

Welche genaue Server-Infrastruktur steht aktuell zur Verfügung (Betriebssystem, PHP-Version, MySQL/MariaDB-Version, verfügbarer Speicherplatz, RAM)?

• TYPO3-System: TYPO3 9.5.31 LTS
• Betriebssystem: Debian GNU/Linux 12 (bookworm)  (VM unter Proxmox)
• PHP-Version: PHP 7.3 (bedingt durch TYPO3 9.5; PHP ≥8 derzeit ausgeschlossen; PHP 7.4 und 8.4 auf System vorhanden)
• Datenbank: 10.11.11-MariaDB auf einem Debian 12 System
• RAM und Speicherplatz wird den VMs für Webserver und Datenbank nach Bedarf zugeteilt

Wie ist die aktuelle Hosting-Situation gestaltet (eigener Server, Managed Hosting, Cloud-Provider)? Ist ein Wechsel des Hosting-Providers vorgesehen oder gewünscht?

• Hosting-Modell:  Eigener Root-Server (kein Managed Hosting, keine externe Cloud-Services)
• Betrieb: Vollständige administrative Kontrolle (Proxmox-, VM- und Netzwerkebene)
• Hosting-Provider-Wechsel: Nicht vorgesehen

Wo wird www.dza.de derzeit gehostet (Provider/Betriebsmodell, RZ-Standort) und auf welcher Serverumgebung läuft das System aktuell (z. B. VM/Root/Dedicated, Betriebssystem, Webserver, PHP-Version, Datenbank, Backup/Monitoring, Reverse-Proxy-Setup)?

Das Typo3-System wird auf einem eigenen Root-Server bei Hetzner betrieben. Die Infrastruktur basiert auf Proxmox VE mit virtuellen Maschinen. SSL/TLS-Termination erfolgt zentral auf der OPNsense-Firewall über das Nginx-Reverse-Proxy-Plugin (ACME). Die Weiterleitung zur TYPO3-VM erfolgt intern per HTTP.

Gibt es verbindliche Vorgaben für ein zukünftiges Hosting bzw. die Serverumgebung (z. B. Standort Deutschland vs. EU/EWR, Zertifizierungsanforderungen an RZ/Provider, Mindestanforderungen an Patch-/Update-Prozesse, Backup/Restore, Logging/Monitoring)? Vor dem Hintergrund der Verarbeitung personenbezogener Daten empfehlen wir ein Hosting in Deutschland auf einer nach ISO/IEC 27001 zertifizierten Server-/RZ-Umgebung. Bitte bestätigen Sie, ob ein solches Zielbild von Ihnen gewünscht ist.

Hosting-Provider: Hetzner

Ein Wechsel des Hosting-Providers ist nicht vorgesehen.

Service und Hosting/Auskunftstool: Was meint "Auskunftstool"? Geht es hier um ein Tool zur statistischen Reichweitenmessung/Tracking des Websiteuserverhaltens oder ist mit Auskunftstool etwas anderes gemeint? Wenn ja bitten wir um kurze Skizzierung des Usecases. 

Es geht um ein geplantes Tool zur Visualisierung vorhandener empirischer Forschungsdaten, das sich aktuell noch in der Konzeptionsphase befindet.

Unter ‚Service und Hosting‘ sind monatlich 2 Stunden für Support/Updates sowie ‚ggf. Hosting‘ genannt. Bitte stellen Sie klar, ob (a) die Serverumgebung durch das DZA gestellt wird und die 2 Stunden ausschließlich Betriebsleistungen auf dieser Infrastruktur abdecken, oder (b) die Bereitstellung der Hosting-Umgebung durch den Auftragnehmer erwartet ist. Wie soll dies im Kosten- und Finanzierungsplan zur Vergleichbarkeit dargestellt werden (separates Modul/Option vs. Bestandteil)? Bekommt der Auftragnehmer administrative Zugriffsrechte (z. B. SSH/Root, Datenbankzugang) auf der vom Hostingdienstleister betriebenen Infrastruktur? Gibt es eine klare Leistungsabgrenzung zwischen dem aktuellen Hostingdienstleister und Auftragnehmer (z. B. wer für Hardware-/Netzwerk- bzw. reine Infrastrukturstörungen zuständig ist).

Hosting / Serverumgebung

• Die Server- und Hosting-Infrastruktur wird durch das DZA bereitgestellt.
• Betrieb auf eigenem Root-Server mit Proxmox VE.
• Eine Bereitstellung der Hosting-Umgebung durch den Auftragnehmer wird nicht erwartet.

Umfang der monatlich vorgesehenen 2 Stunden („Service und Hosting“): Die monatlich vorgesehenen 2 Stunden beziehen sich auf Betriebs-, Wartungs- und Supportleistungen auf Applikationsebene, insbesondere:

• Fehleranalyse und Bugfixing auf TYPO3-Ebene: Kleinere Konfigurationsanpassungen im TYPO3- und PHP/Webserver-Kontext, Abstimmung und Unterstützung bei inhaltlichen oder technischen Änderungen, reine Hosting- bzw. Infrastrukturleistungen (Server, Netzwerk, RZ) sind nicht Bestandteil dieser Position.

Die Betreuung des Betriebssystems der TYPO3-VM ist derzeit nicht verbindlich festgelegt und verbleibt standardmäßig beim DZA; eine optionale Übernahme durch den Auftragnehmer kann als separates Leistungsmodul angeboten werden. Der Auftragnehmer erhält die erforderlichen administrativen Zugriffe auf Applikationsebene.

Die OS-Betreuung ist nicht automatisch Bestandteil der monatlichen 2 Stunden.

Welche technischen Spezifikationen hat die OPNsense Firewall bezüglich SSL/TLS-Offloading? Gibt es besondere Konfigurationsanforderungen?

• OPNsense (als VM auf Proxmox)
• SSL/TLS: TLS-Termination erfolgt aktuell zentral auf der OPNsense
• Zertifikate via ACME-Modul (Let’s Encrypt)
• Reverse Proxy: Nginx-Plugin auf OPNsense
• Mehrere Virtual Hosts (Name-Based VHosts) auf derselben IP

Wird der Staging-Server durch das DZA bereitgestellt (‚bei Bedarf‘) und soll er produktionsnah inkl. Reverse-Proxy/OPNsense/SSL-Offloading aufgebaut sein? Sind personenbezogene Daten auf Staging zulässig (wenn ja, unter welchen Anforderungen) oder ist ausschließlich anonymisiertes Testmaterial vorgesehen?

• Ja, der Staging-Server wird durch das DZA bereitgestellt (bei Bedarf).
• Die Bereitstellung erfolgt innerhalb der bestehenden Hetzner-/Proxmox-Infrastruktur.
• Der Einsatz von anonymisierten oder pseudonymisierten Testdaten ist bevorzugt.
• Personenbezogene Daten sind im Ausnahmefall zulässig, sofern das Staging-System nicht öffentlich zugänglich ist und denselben technischen und organisatorischen Maßnahmen wie das Produktivsystem unterliegt.

Sind Root-/Admin-Zugänge auf dem Produktiv- und Staging-Server für die Durchführung des Updates verfügbar?

• Ja, Root-Zugriff auf VM und Proxmox-Ebene ist verfügbar
• SSH Zugriff auf VMs erfordert VPN Zugang

Wann wird der erwähnte Staging-Server zur Verfügung gestellt und entspricht dieser exakt der Produktivumgebung?

Der Staging-Server wird nicht als 1:1-Duplikat des bestehenden Produktivsystems aufgebaut. Er dient als Zielsystem für die neue TYPO3-Version und wird nach erfolgreicher Migration und Abnahme das bestehende Produktivsystem nach Abnahme ablösen.

Wie umfangreich ist die Website (Anzahl der Seiten, Größe der Datenbank, Anzahl der Datensätze)?

• Datenbank aktuell 2 GB groß
• Etwa 700 Seiten
• Aktuell umfasst die Datenbank 5.883.835 Datensätze. Die Ermittlung erfolgte ohne Bereinigung von Cache-, temporären oder systembedingten Datensätzen.

Existiert eine technische Dokumentation der bisherigen Template-Struktur, TypoScript-Konfiguration und individueller Anpassungen?

Nein

Besteht eine Pipeline und Deployment?

Es ist aktuell keine Deployment Infrastruktur vorhanden. Die Erstellung eines CI Workflows ist möglich.

Wie viele Nutzer*innen sind aktuell im FDZ-System registriert und welches Datenvolumen wird jährlich über den FDZ-Workflow verarbeitet?

• Der FDZ-Workflow unterstützt einen klar abgegrenzten administrativen Prozess zur Bearbeitung von Datenzugriffsanträgen, der Vertragsgenerierung sowie der Anlage von Frontend-Benutzern (Antragstellende). 
• Es handelt sich nicht um ein Massennutzer-System, sondern um einen fachlich und organisatorisch begrenzten Workflow, der durch eine Person fachlich betreut wird.
• Das jährlich verarbeitete Datenvolumen der Datensätze liegt deutlich unterhalb des Gigabyte-Bereichs.  Das Datenvolumen umfasst 200-250 Antragsprozesse pro Jahr. Das entspricht 400-500 txt Seiten pro Jahr.
• Die Bereitstellung von Forschungsdatensätzen ist für die Prozessgestaltung nachrangig und nicht Bestandteil der Datenvolumenermittlung.

FDZ: Existiert eine Dokumentation der aktuellen Access-Datenbank-Struktur (Tabellen, Relationen, Felder)?

Die aktuell genutzte Access-Datenbank fungiert als unterstützendes internes Bestandswerkzeug für einzelne administrative Prozessschritte (u. a. im Kontext der Vertragsgenerierung) und stellt kein strategisches Zielsystem dar.
Kenntnisse über die relevanten Datenstrukturen sind vorhanden und können projektbezogen in dem Umfang aufbereitet werden, der für die Analyse, Integration oder Ablösung einzelner Funktionalitäten erforderlich ist.
Der konkrete Detaillierungsgrad ergibt sich aus den fachlichen und technischen Anforderungen des Projekts.

FDZ: Ist die Implementierung einer REST-Schnittstelle zur Access-Datenbank zwingend erforderlich oder als optionale Leistung zu kalkulieren?

Die REST-Schnittstelle ist als Integrations- und Automatisierungsschnittstelle vorgesehen und im Projekt zu implementieren.
Sie soll internen Drittsystemen (z. B. Legacy-Systemen oder einer Middleware) ermöglichen:

• Datenabruf zu Anträgen/Antragstellenden (read)
• Datensatzaktualisierungen in definiertem Umfang (write)
• Status eines Antrags: abrufbar und aktualisierbar (read/write)
• Prozess-Trigger: definierte Arbeitsschritte sollen aus Drittsystemen anstoßbar sein, insbesondere die Anlage bzw. Steuerung von TYPO3-Frontend-Usern (fe_users) im Rahmen des Workflows

Ein Wegfall der Schnittstelle würde eine vollständige Abbildung und Ausführung aller Prozessschritte innerhalb von TYPO3 erfordern.

Die konkrete technische Ausgestaltung (direkte Anbindung vs. Middleware/Adapter) ist nicht vorgegeben und konzeptionell zu bewerten.

FDZ: Welche konkreten personenbezogenen Daten werden im FDZ-System gespeichert (für DSGVO-Konformität)?

Im FDZ-Workflow werden personenbezogene Daten ausschließlich im Rahmen der Antragsbearbeitung, Vertragsgenerierung und Benutzerverwaltung verarbeitet (z. B. Namen, Kontaktdaten, institutionelle Zugehörigkeit, Zugangsdaten für Frontend-Nutzer).

FDZ: Existiert bereits ein dokumentiertes Löschkonzept gemäß Art. 17 DSGVO?

Ein Löschkonzept gemäß Art. 17 DSGVO ist vorhanden: Die personenbezogenen Daten werden gelöscht, sobald der Zweck der der Speicherung nicht mehr gegeben ist.
Im Zuge der Weiterentwicklung des Workflows kann dieses präzisiert und an die künftige technische Umsetzung angepasst werden.

FDZ: Wie erfolgt aktuell die Protokollierung von Zugriffen auf personenbezogene Daten?

Der Zugriff auf personenbezogene Daten im FDZ-Workflow ist organisatorisch auf einen kleinen, klar definierten Personenkreis beschränkt und über entsprechende Zugriffsrechte geregelt.

Der bestehende Workflow enthält derzeit manuelle Arbeitsschritte, bei denen keine durchgängige technische Protokollierung einzelner Zugriffe und Aktionen erfolgt.

Im Rahmen der Weiterentwicklung des FDZ-Workflows ist die Reduktion manueller Tätigkeiten sowie die Einführung einer angemessenen, datenschutzkonformen technischen Protokollierung (z. B. für Statusänderungen, Benutzeraktionen und automatisierte Prozessschritte) vorgesehen und konzeptionell zu berücksichtigen.

FDZ: In den Unterlagen werden Datenschutz/Vertraulichkeit (AVV inkl. TOMs) sowie für den FDZ-Workflow u. a. Rechte-/Zugriffsregelungen und eine revisionssichere Protokollierung adressiert. Konkrete Mindestvorgaben zu Authentifizierung, Rollen/Rechten und Logging für CMS und technische Komponenten sind jedoch nicht im Detail beschrieben. Bitte konkretisieren Sie zur Vergleichbarkeit der Angebote: Welche Mindestanforderungen gelten für Redaktions- und Administrationszugänge (z. B. verpflichtende Mehr-Faktor-Authentisierung für Admin-Zugänge, Passwortpolicy, IP-Restriktionen/VPN, SSO-Vorgaben)?

Eine weitergehende Konkretisierung von Authentifizierungs- und Zugriffsvorgaben (z. B. MFA, VPN, IP-Restriktionen, SSO) ist in der Ausschreibungsphase nicht vorgesehen. Maßgeblich sind die bestehenden Vorgaben der DZA-IT (u. a. Passwortpolicy). Weitere Maßnahmen können vom Auftragnehmer konzeptionell vorgeschlagen werden und sind ggf. im Projektverlauf abzustimmen.

FDZ: Gehen wir recht in der Annahme, dass ein dokumentiertes Rollen- und Rechtekonzept (TYPO3 inkl. FDZ-Login-/Antragsworkflow) als Teil der Leistung durch den Auftragnehmer zu erstellen bzw. zu aktualisieren ist? Falls ja: Gibt es bereits ein bestehendes Konzept, an das anzuknüpfen ist?

Ein neues Rollen- und Rechtekonzept ist nicht Bestandteil der Leistung.
Für das TYPO3-System existiert bereits ein grundsätzliches redaktionelles Rollenmodell (u. a. Fachbereichsredakteure sowie bereichsübergreifende Hauptredakteure), das im Rahmen des Projekts zugrunde gelegt wird.

FDZ: Der FDZ-Login- und Antragsworkflow liegt in seiner fachlichen Ausgestaltung und Verantwortung vollständig beim FDZ. Eine grundlegende fachliche Neugestaltung oder Neu-Konzeption dieses Workflows ist im Rahmen dieses Auftrags nicht vorgesehen.

Bestandteil der Leistung ist jedoch die technische und organisatorische Weiterentwicklung des bestehenden Workflows, insbesondere zur Verbesserung der DSGVO-Konformität, zur Unterstützung von Lösch- und Auskunftsanforderungen sowie zur Ablösung der bisherigen E-Mail-basierten Datenübertragung durch einen strukturierten, systemgestützten Datenaustausch (z. B. über eine Schnittstelle).

Die fachliche Logik, Zuständigkeiten und Entscheidungsregeln des FDZ bleiben hiervon unberührt.Eine feingranulare Ausgestaltung einzelner Berechtigungen (z. B. für spezielle Inhaltstypen oder Formulare) ist in der Ausschreibungsphase nicht abschließend definiert und kann – sofern erforderlich – im Projektverlauf auf Basis der bestehenden Strukturen abgestimmt werden.

Welche Anforderungen bestehen an die Protokollierung von Sicherheits- und Administrationszugriffen (insb. FDZ-Prozesse, Admin-Backoffice, Reverse Proxy/OPNsense), inkl. Aufbewahrungsdauer, Zugriffsberechtigung auf Logs und Export-/Audit-Anforderungen?

Die Protokollierung erfolgt primär auf Basis der in TYPO3 vorhandenen Logging- und Protokollierungsfunktionen. Erwartet wird eine DSGVO-konforme, datensparsame und revisionssichere Nutzung dieser Bordmittel für administrative und sicherheitsrelevante Vorgänge im CMS; Infrastruktur-Logs liegen im Verantwortungsbereich der DZA-IT.

Kann der erwähnte Barrierefreiheitsbericht bereits vor Angebotserstellung zur Verfügung gestellt werden, um den konkreten Handlungsbedarf einschätzen zu können?

Anbei finden Sie verlinkt den letzten Barrierefreiheitsbericht. Bitte beachten Sie, dass einige Punkte schon umgesetzt wurden (Erklärfilm, leichte Sprache, etliche PDF-Dateien barrierefrei, teilweise bereits Alternativtexte umgesetzt).

Können Sie die (in der Leistungsbeschreibung erwähnten) Schwerpunkte der Barrierefreiheit (Navigation, TAB-Reihenfolge, Kontraste, Alternativtexte) als priorisierte Mindestliste bestätigen, sodass wir diese priorisiert terminieren und bepreisen können?

Ja, diese Punkte haben Priorität. Darüber hinaus sind alle im Prüfbericht identifizierten Barrieren zu berücksichtigen.

Wer beauftragt/finanziert eine externe BITV-/BIK-Prüfung (falls vorgesehen) – und soll eine (Re-)Prüfung innerhalb des Projekts einkalkuliert werden?

Eine externe BITV-/BIK-Prüfung als optionaler, separater Kostenpunkt im Angebot wäre wünschenswert.

In den Vergabeunterlagen ist vorgesehen, dass ein Barrierefreiheitsbericht erst nach Zuschlag bzw. nach der Auftragsvergabe bereitgestellt wird. Zur Vergleichbarkeit der Angebote und zur belastbaren Kalkulation bitten wir um Konkretisierung: Können Sie den Bietern bereits vor Angebotsabgabe zumindest einen anonymisierten Auszug (z. B. Zusammenfassung der wesentlichen Findings, betroffene Seitentypen/Komponenten, Priorisierung/Schweregrade) oder alternativ eine verbindliche inhaltliche Scope-Beschreibung zur Verfügung stellen? Falls nein: Gehen wir in der Annahme recht, dass die Beseitigung von Barrieren im Rahmen des Festpreises auf die in der Leistungsbeschreibung genannten priorisierten Schwerpunkte begrenzt zu kalkulieren ist und weitere, im Bericht identifizierte Maßnahmen, als zusätzliche/optionale Leistungen zu behandeln sind?

Die Beseitigung aller im Barrierefreiheitsbericht identifizierten Barrieren ist im Angebot zu kalkulieren.

"Überschriftentemplates müssen für ausgewählte Backend-Benutzergruppen anpassbar sein (nicht nur zur Formatierung/Schriftgröße)": Ist hier gemeint, dass es die Möglichkeit geben soll, Überschriften sowohl optisch als auch semantisch auszeichnen zu können? Wenn ja: Wie viele Elemente und Plugins gibt es, die die Option haben sollen, die Überschriften entsprechend optisch/semantisch konfigurieren zu können? Falls nein: Was ist gemeint?

Ziel ist es, dass semantische Überschriftenebenen (z. B. H1–H6) bei redaktionell gepflegten Content-Elementen und deren Containern primär der inhaltlichen Struktur, Navigation und Barrierefreiheit dienen und nicht zur reinen optischen Formatierung eingesetzt werden.

Dabei kann es vorgesehen sein, dass unterschiedliche semantische Ebenen mit unterschiedlichen visuellen Grunddarstellungen einhergehen. Ergänzend soll es möglich sein, die optische Darstellung unabhängig von der semantischen Ebene anzupassen, um Fehlbedienungen zu vermeiden.

Die Anforderung bezieht sich auf zentrale TYPO3-Standard-Content-Elemente sowie ausgewählte projektspezifische Content-Elemente (z. B. auch solche, die über MASK definiert sind), soweit diese redaktionell gepflegte Überschriften ausgeben. Die konkrete Auswahl ist nicht abschließend festgelegt und erfolgt im Projektverlauf.

Fachliche Plugins sowie formularinterne Strukturelemente (z. B. Formulare) sind hiervon nicht primär betroffen; relevant ist hier in der Regel die Überschrift des umgebenden Content-Elements.

Erwartet wird ein konzeptioneller Vorschlag, wie diese Ziele unter Berücksichtigung von Barrierefreiheit, Wartbarkeit und Updatefähigkeit erreicht werden können.

Frage zu "Weitere Anpassungen -> Überschriftentemplates": Welche weiteren Parameter außer den genannten Formatierungen und Schriftgröße sollen für Überschriftentemplates anpassbar sein?

Weitere erforderliche Anpassungen ergeben sich aus dem Barrierefreiheitsprüfbericht, der hier  verlinkt ist, bzw. nach der gemeinsamen Detailplanung nach Beauftragung.

Welche WCAG-Konformitätsstufe wird angestrebt (Level AA oder AAA)?

Die Herstellung der Konformitätsstufe WCAG 2.1 Level AA ist zwingend erforderlich. Eine Umsetzung von Level AAA ist für zentrale Inhalte wünschenswert, jedoch nicht verpflichtend.

Sind bereits BITV/BIK-Tests durchgeführt worden und wenn ja, mit welchem Ergebnis und welchen Hauptmängeln?

Es wurden keine eigenen BITV/BIK-Test durchgeführt. Unsere Kenntnisse des Standes der Barrierefreiheit unserer Website beziehen sich auf den oben verlinkten Barrierefreiheitsbericht, in dem auf Konformität mit BITV 2.0 geprüft wurde.

Ist die Erlangung des BIK-BITV-Prüfsiegels verpflichtend oder wird diese angestrebt?

Die Erlangung eines BIK-BITV-Prüfsiegels wird angestrebt, ist jedoch nicht verpflichtender Bestandteil der Leistung, wie auch in der Ausschreibung beschrieben.  

Wie viele Abonnenten hat der aktuelle Newsletter-Verteiler?

Aktuell existieren drei Newsletterverteiler. Davon umfassen zwei jeweils knapp 3.000 Abonnenten. Sie sollen zu einem Verteiler zusammengeführt werden, der voraussichtlich weniger als 5.000 E-Mail-Adressen enthalten wird.

Außerdem existiert ein Presseverteiler, der ca. 100 E-Mail-Adressen enthält.

Wie häufig wird der Newsletter durchschnittlich versendet?

Der Versand des Newsletters erfolgt anlassbezogen, also nicht in einem festen Turnus. 2025 wurden insgesamt 30 Newsletter versendet.

Welche spezifischen Anforderungen bestehen an die Newsletter-Statistik und Bounce-Verarbeitung?

Ein zentrales Anliegen ist die transparente Auswertung nicht zugestellter E-Mails einschließlich der Ursachen.

Erfasst und auswertbar sein sollen insbesondere:

• Gesamtzahl der zurückgekommenen E-Mails
• Differenzierung nach Ursachen, z. B.: unbekannter Empfänger, Postfach voll, falscher Host / Domainfehler, Fehler im Mail-Header, Ursache unbekannt

Die Statistik soll eine nachvollziehbare Qualitätskontrolle des Verteilers ermöglichen.

Darüber hinaus ist eine automatisierte Austragung von Empfängern aus dem Verteiler bei ausgewählten Zuständen vorgesehen,
insbesondere bei dauerhaften Fehlern wie z. B. „unbekannter Empfänger“.

Sollen Newsletter-Templates neu erstellt oder bestehende Templates übernommen werden?

Die bestehenden Newsletter-Templates können als Grundlage weiterverwendet werden, sind jedoch inhaltlich und technisch zu überarbeiten.
Insbesondere soll künftig die Einbettung von Grafiken und Fotos im Newsletter möglich sein.

Zu Punkt „Newsletterfunktion": Ist es denkbar auf Drittdienstleister wie z. B. CleverReach zurückzugreifen?

Ja, ein Wechsel auf ein anderes Tool für die Newsletter ist denkbar, vorausgesetzt, es entsteht kein redaktioneller Mehraufwand für die Pflege der Online-Version des Newsletters auf der Website.

Gibt es einen gewünschten oder verpflichtenden Go-Live-Termin für das TYPO3-Update und die Barrierefreiheits-Anpassungen? Angestrebt wird, bis spätestens Ende Juni 2026 eine barrierefreie Website zu haben, da eine weitere Barrierefreiheitsprüfung für das zweite Halbjahr angekündigt wurde. In den Unterlagen steht Projektbeginn frühestens ab 01.02.2026, gleichzeitig soll Typo3-Update & Barrierefreiheit „so schnell wie möglich“ erfolgen (im Bewertungsraster sogar „möglichst noch 2025“). Bitte erläutern/konkretisieren Sie die realistische Zeitlinie (Start, gewünschter Go-Live, interne Review-Zeiten).

Erwünschter Go-Live wäre Ende Juni 2026. Projektbeginn soll weiterhin so schnell wie möglich sein, hängt aber vom Zeitpunkt des Zuschlags ab. Interne Reviewzeiten sollen in dem Zeitraum enthalten sein, sind aber konkret nach der Auftragsvergabe abzustimmen.

Wie viele Redakteure arbeiten aktuell mit dem TYPO3-Backend und welche technischen Vorkenntnisse haben diese?

Es gibt derzeit sieben Redakteur*innen mit sehr unterschiedlich ausgeprägter Expertise und bearbeiteten Bereichen. Daher ist eine grundlegende Schulung auf der dann aktualisierten Typo3-Version sehr wichtig.

Wann soll die Backend-Schulung idealerweise stattfinden (vor oder nach Go-Live)? Soll diese vor Ort in Berlin oder remote erfolgen?

Eine Backend-Schulung sollte vor dem Go-Live erfolgen, aber erst dann, wenn bereits mit der geupdateten Typo3-Version gearbeitet werden kann. Die Schulung kann gerne remote sein, evtl. auch mit Aufzeichnung, die als Teil der Schulungsunterlagen bereitgestellt werden sollte.

Zur vorgesehenen Schulung bitten wir um Konkretisierung: Sind ein oder mehrere Schulungstermine geplant und sollen diese remote oder vor Ort in Berlin stattfinden? Welcher Umfang wird erwartet (Dauer je Termin, Zielgruppe, Themenschwerpunkte)? Sollen zudem deutschsprachige Schulungsunterlagen bereitgestellt werden und in welcher Detailtiefe?

Ein Schulungstermin könnte ausreichen und kann gerne Remote erfolgen. Es sollte eine umfassende Schulung erfolgen, für zwei Redakteur*innen soll auch die Anpassung von Templates vermittelt werden. Es soll neben einer grundlegenden Einführung in Typo3 auch Raum für spezifische Fragen einzelner Nutzer*innen sein. Die Erstellung von Schulungsunterlagen (in deutscher Sprache) ist Teil der Ausschreibung und sollte sehr fundiert erfolgen, wobei die Aufzeichnung des Schulungstermin Teil der Unterlagen sein kann.

Wer ist auftraggeberseitig der Hauptansprechpartner für technische und organisatorische Fragen während des Projekts?

Stefanie Hartmann (Presse- und Öffentlichkeitsarbeit) für organisatorische Fragen; Paul Steffen (IT-Administrator) für technische Fragen.

Gibt es einen dedizierten IT-Ansprechpartner beim DZA für infrastrukturelle Themen?

Paul Steffen (IT-Administrator)

Was fällt konkret unter die "2 Stunden monatliche Betreuung" – nur reaktiver Support oder auch proaktive Wartung (z. B. TYPO3-Security-Updates)?

Die monatlichen 2 Stunden umfassen sowohl reaktive als auch proaktive Leistungen, insbesondere:

• reaktiver Support bei Störungen und Fehlern,
• proaktive Wartung, insbesondere TYPO3-Core- und sicherheitsrelevante Extension-Updates,
• kleinere Konfigurations- und Pflegearbeiten im laufenden Betrieb.

Die Leistungen beziehen sich auf die Applikationsebene (TYPO3) und angrenzende, applikationsnahe Tätigkeiten.

Ist auch Grafik-Support gewünscht (Erstellung von Grafiken, neue Design etc.) oder gibt es eine separate Grafik-Webdesign-Agentur?

Es gibt keine separate Grafik- oder Webdesign-Agentur. Grafik- oder Design-Support (z. B. kleinere Anpassungen, grafische Ergänzungen) ist in geringem Umfang Bestandteil der Betreuung. Umfangreichere Design- oder Neugestaltungsleistungen sind nicht Gegenstand der monatlichen Betreuung und gesondert zu vereinbaren.

Wie soll die Dokumentation und Abrechnung der monatlichen Stunden erfolgen?

Die Dokumentation der erbrachten Leistungen soll nachvollziehbar und transparent erfolgen.

Die Nutzung eines Ticketsystems wird bevorzugt, um:

• Supportanfragen strukturiert zu erfassen,
• Bearbeitungsstatus und Reaktionszeiten nachvollziehen zu können,
• die aufgewendeten Zeiten je Vorgang zu dokumentieren.

Alternativ sind gleichwertige Verfahren zulässig, sofern sie:

• eine eindeutige Zuordnung von Leistung, Zeitaufwand und Zeitraum ermöglichen,
• eine monatliche übersichtliche Leistungs- und Stundenaufstellung bereitstellen.

Die Abrechnung erfolgt auf Basis der tatsächlich angefallenen Zeiten.

Die Dokumentation soll Art der Tätigkeit, Datum und Zeitaufwand nachvollziehbar ausweisen.

Welcher Reaktionszeitraum wird bei Support-Anfragen erwartet (z. B. 24h bei kritischen Issues)?

Bei kritischen Störungen sollte die Reaktionszeit innerhalb regulärer Geschäftszeiten (10 bis 18 Uhr) unter einer Stunde liegen und die qualifizierte Antwort bei unter 24 Stunden (Latenzzeit).

Bei wesentlichen Störungen sollte die Reaktionszeit innerhalb regulärer Geschäftszeiten (10 bis 18 Uhr) unter zwei Stunden liegen und die qualifizierte Antwort bei unter 48 Stunden.

Bei geringfügigen Störungen sollte die Reaktionszeit innerhalb regulärer Geschäftszeiten (10 bis 18 Uhr) bei ca. zwei Stunden liegen und die qualifizierte Antwort bei unter 3 Tagen.

Sollen nicht genutzte Stunden in den Folgemonat übertragen werden können?

Eine Übertragung nicht genutzter Stunden in den Folgemonat ist nicht zwingend erforderlich und wird nicht vorausgesetzt.

Sollen die genannten langfristigen Erweiterungen (Veranstaltungsarchiv, Newsletterarchiv, Anpassung Publikationssuche, statistisches Auskunftstool) bereits konkret im Angebot kalkuliert werden oder nur als separate optionale Positionen?

Die genannten Leistungen sollen gerne als separate optionale Positionen im Angebot kalkuliert werden.

Falls konkrete Kalkulation gewünscht: Können Sie nähere Spezifikationen zu diesen Funktionen zur Verfügung stellen?

Zu den genannten Erweiterungen liegen derzeit noch keine detaillierten fachlichen oder technischen Spezifikationen vor. Die Konkretisierung dieser Funktionen soll zu einem späteren Zeitpunkt und in Zusammenarbeit mit der beauftragten Agentur erfolgen.

Gibt es ein Gesamtbudget oder Teilbudgets für verschiedene Leistungsbereiche, die wir bei der Angebotserstellung berücksichtigen sollten?

Ein konkretes Gesamt- oder Teilbudget kann derzeit nicht benannt werden. Die Wirtschaftlichkeit des Angebots ist ein wesentliches Vergabekriterium. Die Vergabe steht zudem unter dem Vorbehalt der Mittelbewilligung.

Existieren noch Verträge mit bisherigen Dienstleistern oder Lizenzvereinbarungen für aktuell genutzte Extensions, die zu beachten sind?

• Für TYPO3 bestehen keine laufenden Lizenzverträge.
• Es werden überwiegend freie Extensions aus dem TER sowie Eigenentwicklungen eingesetzt.
• Kommerzielle Extensions mit aktiven Lizenz- oder Wartungsverträgen sind nicht im Einsatz.
• TYPO3 Core steht unter der GPL v2 oder höher.
• TYPO3 Extensions gelten in der Regel als abgeleitete Werke des TYPO3 Core.
• Damit müssen TYPO3-Extensions grundsätzlich GPL-kompatibel lizenziert sein.

Wie viele Referenzen sollen pro geforderter Kategorie eingereicht werden (mindestens/maximal)?

Es ist keine Mindest- oder Höchstanzahl an Referenzen pro Kategorie vorgegeben. Üblich sind ein bis zwei aussagekräftige Referenzen je Kategorie. Eine Referenz kann mehrere Kategorien abdecken, sofern dies nachvollziehbar dargestellt wird.

Welcher maximale Zeitraum wird für die Referenzen akzeptiert (z. B. Projekte der letzten 3/5 Jahre)?

Referenzen aus den letzten fünf Jahren sind wünschenswert. Aufgrund der technologischen Weiterentwicklung von TYPO3 sollten ältere Referenzen nur in begründeten Ausnahmefällen berücksichtigt werden, etwa bei langfristig betreuten Projekten mit kontinuierlicher Weiterentwicklung.

Welche Mindestangaben werden pro Referenz erwartet?

Pro Referenz sind mindestens anzugeben:

• Kunde bzw. anonymisierte Kundenbeschreibung
• Kurzbeschreibung des Projekts und Leistungsumfangs
• Projektlaufzeit
• TYPO3-Bezug
• Ansprechpartner mit Kontaktdaten sowie – sofern öffentlich – ein Link zum Projekt

Angaben zum Projektvolumen sind optional.

Gibt es Mindestanforderungen an das Projektvolumen oder die Projektlaufzeit der Referenzprojekte?

Nein

Können auch laufende Projekte als Referenz eingereicht werden oder nur abgeschlossene Projekte?

Es können auch laufende Projekte als Referenz eingereicht werden.

Werden Referenzen höher bewertet, wenn ein Ansprechpartner beim Referenzkunden angegeben wird, der für Rückfragen zur Verfügung steht?

Vorschlag: Die Angabe eines Ansprechpartners beim Referenzkunden führt nicht zu einer höheren Bewertung, ist aber zur Nachvollziehbarkeit hilfreich.

In den Vergabeunterlagen werden umfangreiche Anforderungen an Datenschutz/Vertraulichkeit (u. a. DSGVO/BDSG, AVV inkl. TOMs) sowie an eine strukturierte Leistungserbringung und ein belastbares Service- und Betreuungskonzept gestellt. Vor diesem Hintergrund gehen wir davon aus, dass ein etabliertes Informationssicherheits- und Qualitätsmanagementsystem die Nachweisführung und Bewertung dieser Anforderungen unterstützt. Unser Unternehmen ist nach ISO/IEC 27001 sowie ISO 9001 zertifiziert. Gehen wir recht in der Annahme, dass vorhandene Zertifizierungen nach ISO/IEC 27001 und ISO 9001 als geeigneter Nachweis für die geforderte geordnete Leistungserbringung sowie Informationssicherheit/Datenschutz gewertet werden können (Eignung und/oder im Rahmen der Qualitätskriterien, insb. Umsetzungskonzept sowie Service- und Betreuungskonzept)? Gehen wir auch recht in der Annahme, dass wir die gültigen Zertifikate bereits mit dem Angebot einreichen dürfen, um die Anforderungen nachvollziehbar zu belegen?

Ja, vorhandene ISO/IEC 27001- und ISO 9001-Zertifizierungen können als geeigneter Nachweis für eine geordnete Leistungserbringung sowie für Informationssicherheit und Datenschutz gewertet werden (Eignung und Qualitätskriterien, insbesondere Umsetzungskonzept sowie Service-/Betreuungskonzept).

Die Einreichung der gültigen Zertifikate bereits mit dem Angebot ist zulässig und erwünscht, um die Anforderungen nachvollziehbar zu belegen.

DSGVO-Konformität: In welcher Form ist eine nachvollziehbare Datenlöschung gewünscht? Ist ein Eintrag im TYPO3-System-Log ausreichend? Oder ist ein dediziertes Tool im Backend (Backend Module) gewünscht?

Da die Bearbeitung von Selbstauskunfts- und Löschanfragen Teil der DSGVO-Konformität ist, wird eine Lösung angestrebt, die diese Prozesse nachvollziehbar unterstützt und mit möglichst geringem manuellem Aufwand für die Mitarbeitenden umsetzbar ist. Eine (teilweise) Automatisierung, etwa zur strukturierten Verarbeitung, Fristenüberwachung oder Dokumentation, ist ausdrücklich erwünscht.

Die Nachvollziehbarkeit der Löschung erfolgt durch eine datensparsame Dokumentation des Löschvorgangs, bei der ausschließlich Metadaten (z. B. Art und Zeitpunkt der Löschung, betroffene Datenkategorien, auslösender Vorgang) erfasst werden; die gelöschten personenbezogenen Daten selbst werden nicht gespeichert. Die konkrete technische Umsetzung ist nicht vorgegeben und soll vom Auftragnehmer konzeptionell vorgeschlagen werden, sofern Nachvollziehbarkeit und DSGVO-Konformität gewährleistet sind.

Bitte teilen Sie uns mit, ob und in welcher Form Sie eine kontinuierliche Verbesserung des Betriebs und der Pflege des Internetauftritts erwarten (z. B. regelmäßige Review-Termine, Vorschlagslisten für Optimierungen, Kennzahlen-/Reporting-Pflichten) und ob entsprechende Prozesse oder Formate bereits vorgegeben sind oder vom Auftragnehmer konzeptionell vorgeschlagen werden sollen.

Derzeit sind keine festen Prozesse oder Formate für kontinuierliche Reviews vorgegeben. Eine regelmäßige, nachvollziehbare Dokumentation der umgesetzten Aufgaben (insb. im Rahmen der Abrechnung) ist jedoch verpflichtend. Weitergehende Vorschläge zur strukturierten Weiterentwicklung können optional eingebracht werden.

Frage zu "Service und Hosting": Sofern Hosting angeboten werden soll: Können Sie Informationen zu aktuellen Zugriffszahlen (Durchschnitt, Peaks) nennen?

Im Kalenderjahr 2025 wurde 31.328mal auf die Website des DZA zugegriffen. Es gab 78.664 Seitenansichten und 9.165 Downloads. Der Peak lag bei 178 Besuchen an einem Tag. Ein Wechsel des Web-Hosters ist allerdings nicht vorgesehen.

Gehen wir in der Annahme recht, dass für die als Werkleistungen vorgesehenen Projektbestandteile zu Projektbeginn ein Pflichtenheft (fachlich/technische Spezifikation inkl. Abnahmekriterien) zu erstellen ist, das nach Freigabe durch das DZA die verbindliche Projekt- und Abnahmegrundlage bildet, und dass die Erstellung dieses Pflichtenhefts Bestandteil des Festpreises (Werkvertrag) ist? Bitte bestätigen Sie zudem, ob Teilabnahmen anhand der im Pflichtenheft definierten Abnahmekriterien je Arbeitspaket/Modul vorgesehen sind.

Die Erstellung eines formalen Pflichtenhefts ist nicht zwingend vorgesehen. Alle Abnahmekriterien ergeben sich aus der Leistungsbeschreibung und dem Werkvertrag. Teilabnahmen erfolgen gemäß den dort definierten Leistungsbestandteilen.

Zur postalischen Angebotsabgabe bitten wir um Konkretisierung: Wie viele Exemplare sind einzureichen (z. B. 1x Original, ggf. 1x Kopie)?

Eine einfache Ausfertigung ist ausreichend.

Zur Angebotsabgabe und Preisdarstellung bitten wir im Sinne der Vergleichbarkeit um Konkretisierung: Gibt es eine Formatvorgabe für den Kosten- und Finanzierungsplan (z. B. Gliederung/Tabellenstruktur), und welche Preisbestandteile fließen in die wirtschaftliche Wertung ein? Bitte bestätigen Sie insbesondere, wie folgende Positionstypen darzustellen sind und ob sie wertungsrelevant sind: Festpreise für Werkleistungen/Module (inkl. Abnahme), monatliche Pauschalen bzw. das 2-Std.-Kontingent für Betrieb/Service (inkl. Abrechnung von Mehrstunden), Stundensätze für Weiterentwicklung/zusätzliche Leistungen, Optionen/Alternativpositionen (z. B. zusätzliche Zielversion, optionales Auskunftstool).
Soll der wertungsrelevante Gesamtpreis ausschließlich aus den verpflichtenden Leistungen bestehen und Optionen/Alternativen separat auszuweisen sein?

Es gibt keine feste Formatvorgabe. Wertungsrelevant sind ausschließlich die verpflichtenden Leistungen. Optionen und Alternativen sind separat auszuweisen und nicht wertungsrelevant.

Im Bewertungsraster (Anlage 8, Punkt f) wird "Besonderheiten wurden beschrieben" als separates Bewertungskriterium aufgeführt. Was ist konkret unter "Besonderheiten" zu verstehen (technische Herausforderungen, innovative Lösungen, spezielle Anforderungen)?

Unter „Besonderheiten“ sind insbesondere projektspezifische Aspekte zu verstehen, z. B. besondere technische Herausforderungen, innovative oder effiziente Lösungsansätze, spezielle fachliche, organisatorische oder rechtliche Anforderungen.

Können wir unsere bestehenden TOM-Dokumente (ISMS/TOM-Katalog) inkl. ISO 27001 / ISO 9001-Zertifikaten als Nachweis einreichen und die Anlage ‚TOMs nach Art. 32 DSGVO‘ darauf referenzieren (Mapping), oder erwarten Sie zwingend die vollständige Beantwortung der TOM-Checkliste im vorgegebenen Format? Ist der ausgefüllte AVV inkl. TOMs bereits mit dem Angebot einzureichen oder erst im Zuge der Zuschlagserteilung/Vertragsunterzeichnung?

Bestehende ISMS-/TOM-Dokumente sowie ISO/IEC 27001- und ISO 9001-Zertifikate können als Nachweis eingereicht werden. Eine referenzierende Zuordnung (Mapping) zur Anlage „TOMs nach Art. 32 DSGVO“ ist ausreichend, sofern alle Anforderungen vollständig und nachvollziehbar abgedeckt sind. Der ausgefüllte AVV inkl. TOMs ist erst im Zuge der Zuschlagserteilung bzw. Vertragsunterzeichnung vorzulegen.

Ist eine Abnahme in Etappen gewünscht (z. B. nach Update, nach Barrierefreiheit) oder nur eine finale Gesamtabnahme?

Eine Abnahme in zu vereinbarenden Etappen ist erwünscht. Zusätzlich ist eine finale Gesamtabnahme vorgesehen.

Ist eine Abrechnung nach tatsächlichem Aufwand oder als Festpreis gewünscht?

Ja, für unsere eigene Kostenplanung ist ein Festpreis erforderlich.

Sind Teilrechnungen nach definierten Meilensteinen möglich?

Ja, Teilrechnungen nach gemeinsam zu definierenden Meilensteinen werden angestrebt.

Im Zusammenhang mit einer ggf. vorgesehenen Serverinfrastruktur über Unterauftragnehmer bitten wir um Bestätigung: Reicht zur Angebotsabgabe die Benennung der betroffenen Teilleistung (z. B. Hosting/Serverbetrieb) und – sofern bereits feststehend – der Name des Unterauftragnehmers aus, und können die weiteren Unterlagen/Nachweise (z. B. AVV-Unterauftragsnehmerangaben, TOMs/Zertifikate des Rechenzentrums/Providers, sonstige Erklärungen) erst nach Zuschlag bzw. im Zuge der Vertragsfinalisierung eingereicht werden?

Das Hosting der Website verbleibt beim DZA auf einem eigenen Root-Server bei Hetzner; ein Hosting durch den Auftragnehmer ist nicht vorgesehen. Die Bezeichnung „Service und Hosting“ bezieht sich auf applikationsnahe Betriebs- und Supportleistungen (z. B. TYPO3-Updates), nicht auf Infrastrukturleistungen. Unterauftragnehmer können für klar abgegrenzte Teilleistungen benannt werden. Die genannten Nachweise können bereits mit dem Angebot eingereicht werden. Spätestens vor Zuschlagserteilung müssen sie vorliegen (siehe Bewerbungs- und Angebotsbedingungenzum Vergabeverfahren).

Bezieht sich die im Mustervertrag genannte 12-monatige Gewährleistung auf alle Werkleistungen oder nur auf bestimmte Teilleistungen?

Die Gewährleistung bezieht sich auf alle Werkleistungen.

Wie ist die Abgrenzung zwischen Gewährleistungsansprüchen und kostenpflichtigem Support nach Ablauf der Gewährleistungsfrist definiert?

Gewährleistungsansprüche umfassen die Beseitigung von Mängeln, die schon bei der Abnahme angelegt waren. Alle Leistungen, die über die Mängelbeseitigung hinausgehen (Erweiterungen, Weiterentwicklungen etc.) stellen keine Gewährleistung dar, sondern werden wie kostenpflichtiger „support“ behandelt.