How ClickHouse security measures for NIS2 map to your cluster
ClickHouse can support several NIS2 risk management measures, but it does not make an entity compliant on its own, and NIS2 creates no certificate of compliance. If your organization is an in-scope entity running ClickHouse for analytics, the practical question is which Article 21 measures your cluster configuration can evidence and which depend on governance you run outside the database. Directive (EU) 2022/2555 applies to entities classified as essential or important (Article 3), and both face the same risk management obligations in Article 21. Commission Implementing Regulation (EU) 2024/2690 sets detailed technical requirements for specific provider types such as cloud and data center providers, so check whether it applies to your service model before relying on it. National competent authorities supervise compliance through inspections, audits and information requests, and DeployOpen prepares systems and evidence for that review without deciding the outcome.
Some measures map directly to cluster settings. Supported versions are a configuration and change process question: the ClickHouse security policy lists which release lines receive security updates, so your upgrade plan should keep the cluster on a supported line. Access control maps to users, roles, row policies, settings profiles and quotas, and it starts with restricting the default user. External authenticators such as LDAP, Kerberos, X.509 certificates and JWT let you tie database access to your identity provider. Replication and tested backups address availability and recovery, but the backup documentation is clear that replication alone does not protect against human error or corruption, so restore tests must be part of the plan. Encryption and incident detection depend on how you configure TLS, storage and log retention, and on who reviews the alerts.
Other measures depend on governance rather than on ClickHouse. Policies, risk assessments, supplier security in your contracts, training, incident reporting timelines under Article 23, and management accountability under Article 20 are decisions your organization owns. Before scoping work, confirm your entity category with national transposition law and your competent authority, check whether your service falls under 2024/2690, and map each Article 21 measure to a named owner, a cluster control and an evidence source. A quote from DeployOpen should follow that written mapping, so the scope reflects what your organization actually needs to demonstrate.
Which NIS2 risk management measures ClickHouse configuration addresses
This table maps the main Article 21 risk management measure areas to specific ClickHouse capabilities and the configuration each one needs. Read each row as a starting point for your own risk assessment, then confirm the details against your environment and the implementing regulation. The main takeaway is that most NIS2 evidence depends on configuration you set and can show, not on features alone.
| Measure area | ClickHouse capability | Configuration needed |
|---|---|---|
| Patching and vulnerability handling | Supported release lines with security updates, per the ClickHouse security policy | Run only supported versions (currently 26.9, 26.8, 26.7 and 26.3 per the policy). Record the version in each node, subscribe to security notices, and test upgrades in pre-production first. |
| Secure development and change control | Stable and LTS release lines, with changelogs noting backward-incompatible changes | Pin versions in deployment code, read the changelog before each upgrade, and keep a dated record of every change and its approval. |
| Access control | Users, roles, row policies, settings profiles and quotas | Create named users and roles through SQL, grant least privilege, apply row policies to restrict data, and set quotas and profiles for resource limits. |
| Default account hardening | The default user starts with all permissions | Restrict or disable the default user, and confirm that no shared or unused accounts keep administrative rights. |
| Strong authentication | External authenticators: LDAP, Kerberos, SSL X.509 certificates, HTTP authenticator and JWT | Connect ClickHouse to your central directory or identity provider, enforce certificate-based or token-based sign-in for service accounts, and document which method each account uses. |
| Cryptography and encryption | TLS for client and inter-node connections, plus certificates used by external authenticators | Enable TLS for client and replication traffic, manage certificate issuance and rotation, and confirm which at-rest encryption your storage layer provides. Confirm at-rest options with your ClickHouse version. |
| Resilience and recovery | ReplicatedMergeTree with ClickHouse Keeper, which resyncs a recovered replica automatically | Run at least three Keeper nodes on dedicated hosts in production, and keep replicas on separate failure domains. Replication does not protect against human error or corruption. |
| Backup and recovery | BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage | Schedule backups off-cluster, keep copies in a separate account or location, and run regular restore tests on a spare cluster. A backup never test-restored may not restore when needed. |
| Incident detection and logging | System tables such as query and session logs, plus Prometheus metrics | Forward authentication and query events to your SIEM, define alerts for failed logins and privilege changes, and keep log retention aligned with your incident response procedure. |
Why patching on supported ClickHouse versions is the first control to check
Before you assess any other NIS2 measure for a self-managed ClickHouse cluster, confirm that every node runs a version that still receives security updates. The ClickHouse security policy lists 26.9, 26.8, 26.7 and 26.3 as currently supported with security updates, and treats all other versions as unsupported. A cluster on an unlisted version has no vendor security path, so an incident response or supervisory inquiry will expose that gap quickly. Ask the vendor to confirm the current list on the day you plan, because the policy is the authoritative source and the list changes as new lines ship.
The release rhythm sets the planning cadence. According to the ClickHouse production FAQ, stable releases ship roughly monthly, the three latest stable releases receive diagnostics and bug fix backports, and LTS releases ship twice a year and are supported for a year after release. Choose a target line deliberately: a stable line gives you frequent fixes but requires regular upgrades, while an LTS line gives a longer support window with fewer jumps. Document which line you run and when it leaves support, so the date becomes an input to your patch calendar.
Patching is safe only if you test it first. The ClickHouse production FAQ recommends a pre-production environment with representative data and queries, and reading the changelog before upgrading because minor backward-incompatible changes can occur. Run your heaviest ingestion and query workloads against the target version, check the changelog for changed defaults and removed settings, and record the result as change evidence. Your upgrade procedure, including rolling order across replicas and rollback steps, should be approved before the production window opens.
Configuring access, encryption, backups and detection in ClickHouse
Access control is where most self-managed ClickHouse exposure starts, because a fresh server begins with a default user that holds all permissions. ClickHouse can delegate sign-in to external authenticators, including LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication, so accounts can follow your central identity process. Inside the server, users, roles, row policies, settings profiles and quotas define what each identity may do and how much it may consume. The access control documentation recommends managing these objects through SQL so changes are reproducible and reviewable.
- Restrict the default user: Remove its privileges or disable its network access before any production traffic arrives, and create named administrative accounts.
- Map identities to roles: Grant privileges to roles and assign roles to users, so access reviews check a small set of role memberships.
- Apply row policies: Limit which rows a role can read when one table serves several teams or data classes.
- Set profiles and quotas: Cap memory, query time and request volume so one identity cannot starve the cluster or exfiltrate large volumes unnoticed.
- Choose an external authenticator deliberately: Confirm which methods your version supports and how group membership maps to ClickHouse roles.
Confirm the authenticator options, parameter names and role-mapping behavior against the documentation for your exact version before you write the configuration.
Encryption in transit protects queries, results and credentials moving between clients, cluster nodes and Keeper. ClickHouse supports TLS for its client and inter-server connections, and SSL X.509 certificates can also serve as an authentication factor, which ties transport security to identity. Keeper coordination traffic and replication traffic should be encrypted and restricted to the cluster network. Encryption at rest, network exposure rules and Keeper hardening are covered in depth in ClickHouse security hardening, so this tab focuses on what NIS2 risk management needs you to decide and evidence.
- Enable TLS on every listener: Cover native, HTTP and inter-server endpoints, and disable plaintext ports that are not needed.
- Plan certificate lifecycle: Record who issues, renews and revokes certificates, and how Keeper and replica certificates rotate without downtime.
- Restrict exposure: Allow only application subnets and administrative hosts to reach the database ports.
- Protect backup transport: Confirm that traffic to S3-compatible or Azure Blob Storage targets uses encrypted endpoints and that storage credentials are scoped and rotated.
- Document the boundary: State which data is encrypted in transit, between which parties, and which controls cover data at rest.
Before relying on these settings, confirm the exact TLS configuration keys and supported cipher behavior for your ClickHouse version and your security baseline.
NIS2 Article 21 risk management expects measures that keep systems recoverable, and backups are a core part of that. ClickHouse BACKUP and RESTORE handle full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The backup documentation is explicit that replication alone does not protect against human error or corruption, because a bad DROP or DELETE propagates to every replica. Replicas do help recover from node loss, since a recovered replica syncs missing data from a healthy one automatically.
- Back up to independent storage: Store backups outside the failure domain of the cluster, with access separated from database administrators.
- Schedule full and incremental runs: Define frequency and retention based on your recovery expectations, and record them in your policy.
- Test restores regularly: The documentation warns that a backup never test-restored will probably not restore properly, so restore into a spare cluster on a set cadence.
- Verify the result: Compare row counts, checksums or sampled queries against the source after each restore test.
- Keep the evidence: Retain run logs, restore test records and any failures with the corrective actions taken.
Confirm backup syntax, object storage settings and restore behavior for your version, and agree recovery time and data loss targets with the business before choosing a schedule.
NIS2 Article 23 requires significant incidents to be reported within set deadlines, which means you need to notice them first. ClickHouse records activity in system tables and server logs, including query history, sessions and authentication events, that can feed a SIEM or log platform. Detection depends on deciding in advance which events matter, keeping them long enough to investigate, and protecting them from tampering. The sibling guidance on audit logging covers the detailed query_log and session_log design, so this tab concentrates on the detection use cases NIS2 readiness requires.
- Watch authentication failures: Alert on repeated failed sign-ins, new source addresses and logins by accounts that should be inactive.
- Review privileged and bulk activity: Flag grants, role changes,
DROPandALTERstatements, and unusually large exports. - Monitor replication and Keeper health: Treat readonly replicas, lagging replicas and Keeper quorum loss as security-relevant availability events.
- Ship logs off the host: Forward server and system table data to a central store that administrators cannot silently edit.
- Define response steps: Assign owners, escalation paths and reporting clocks for each alert type.
Confirm the names of system tables, log settings and retention behavior for your version, and test that alerts fire on simulated events in a non-production environment.
Evidence auditors and supervisors ask for under NIS2
A supervisor inspecting a NIS2 entity will ask for proof that the risk management measures work in practice, not just that they were written down. The cards below list the records a self-managed ClickHouse cluster should produce and keep, so the evidence exists before an inspection or security audit asks for it. NIS2 issues no certificate of compliance, so these records are inputs to supervision, not a substitute for it.
Version inventory against the supported list
Keep a dated record of every ClickHouse server version running in each environment, including test and recovery clusters. Compare it against the versions the ClickHouse security policy lists as supported with security updates, currently 26.9, 26.8, 26.7 and 26.3, and flag anything else as unsupported and due for a planned upgrade. Export the running version from each node, not from the deployment file, so the inventory reflects what is actually live. Retain one snapshot per month and per change window.
Upgrade change records and pre-production results
For each upgrade, keep the change ticket, the changelog reviewed before the move, the results of tests run on a pre-production environment with representative data and queries, and the rollback plan. The ClickHouse production guidance asks operators to read the changelog because minor backward-incompatible changes can occur. Record who approved the change and when it reached each replica, so a supervisor can trace a patch from disclosure to production.
Access configuration exports and periodic reviews
Export users, roles, row policies, settings profiles and quotas on a fixed schedule, and store each export with its review sign-off. Confirm the default user no longer holds its initial full permissions, since ClickHouse documents that it starts with all of them. Check that external authenticators, such as LDAP or JWT, are the source of identity where your organization requires central control. A review should show who can reach each database and why, and should record removed access.
Backup logs and restore test records
Keep the output of each BACKUP run, including its destination, time, size and success status, along with the storage location and retention setting used. A backup that has never been restored is unproven, so keep a dated record of each restore test run on a spare cluster, the tables restored, the row counts or checksums compared, and the time taken. Replication alone does not protect against human error or corruption, so these records show that recovery was tested, not assumed.
Replication and Keeper health records
Retain periodic snapshots of replica status, replication queue length and the health of the ClickHouse Keeper ensemble. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, so record node count, placement and any failover events. Log each replica failure, the time it recovered and the confirmation that it resynced from a healthy replica without manual intervention. These records show that availability, one of the core NIS2 risk management concerns, was monitored and that outages were handled.
Incident detection logs from system tables
Keep the logs that show how suspicious activity would have been detected. Export relevant entries from query and session logs, including failed authentication attempts, new or changed users and grants, and unusual query volume, to your central log platform on a schedule. Document the alert rules that act on them and the people who respond. Supervisors look for a working chain from detection to response, and for evidence that incidents were reported within the timeframes your national transposition law sets, which you should confirm with your competent authority.
Sequence for a NIS2-ready ClickHouse configuration
This sequence turns a self-managed ClickHouse cluster into one whose security measures you can explain, test and show to a national competent authority. Each step produces an artifact that feeds the evidence folder at the end.
Confirm entity scope with counsel
Before changing anything, your legal or compliance team confirms whether your organization is in scope under NIS2 and which category applies, essential or important. This depends on the national transposition law in each Member State where you operate, not on the Directive text alone, and the Commission's proposed amendments of January 2026 are still a proposal. Ask counsel to record the sector, the entity category and the national law reference in writing. Done when that memo exists and names the systems the ClickHouse cluster supports, because those systems define the measures you will need to evidence.
Inventory ClickHouse versions and pick a supported line
Your platform team lists every ClickHouse server, Keeper node and client tool in use, with its exact version. Compare each version against the ClickHouse security policy, which lists the lines currently receiving security updates. Versions outside that list are unsupported and must be scheduled for upgrade, using the release notes and a pre-production test with representative data and queries as the production FAQ recommends. Choose a target line for each environment and document why. Done when the inventory shows every node on a supported version or carries a dated upgrade item in your change system.
Restrict the default user and move access to external authenticators
The default user starts with all permissions, so the security team disables or restricts it and creates named administrative accounts. Connect ClickHouse to your identity provider through the supported external authenticators, such as LDAP, Kerberos, X.509 certificates or JWT, depending on your directory. Then define roles, grant them through SQL, and add row policies and settings profiles so each team sees only the data it needs. Your identity team confirms that leavers lose access by removing the directory entry. Done when a test login with the default user fails, each role has a documented owner, and an access review export lists who holds which privileges.
Enable TLS and plan encryption
Enable TLS for client connections and inter-node traffic using certificates issued by your internal certificate authority, and make sure plain-text ports are closed on untrusted networks. Verify each connection with a test client that refuses unencrypted sessions. Next, decide how data at rest is protected: whether disk-level encryption on the hosts, encrypted object storage or ClickHouse-level options fit your platform, and where the keys are held. Confirm the approach with your security architect, since the choice affects backups and restore procedures. Done when a configuration review shows encrypted listeners, a documented key custody model and a recorded decision for each storage tier.
Configure BACKUP to separate storage
Set up BACKUP and RESTORE to write full and incremental backups to storage that is isolated from the production cluster, such as a separate S3-compatible bucket or Azure Blob Storage container with its own access policy. The backup documentation notes that replication alone does not protect against human error or corruption, so backups must be independent of the replicas. Restrict write and delete permissions on the backup target, and enable a schedule that your operators monitor. Done when a scheduled backup completes, its metadata is listed, and the backup target rejects deletion by the database service account.
Schedule restore tests on a spare cluster
A backup that has never been restored will probably not restore when it is needed, so the operations team restores backups on a spare cluster on a set schedule. Each test restores a defined set of tables or partitions, runs row count and checksum comparisons against known values, and records the time taken and any errors. Failed tests open an incident and a corrective action. Done when the test log shows dated restores with pass or fail results, and the spare cluster is torn down or isolated after each run so that test data does not leak into production.
Set up detection through system tables and monitoring
Use ClickHouse system tables that record logins, queries and errors to detect misuse and failures, and route them to your monitoring stack. Define alerts for failed authentication, privilege changes, queries from unexpected users, replication lag, Keeper health and backup failures. Mask sensitive literals in logged queries so that personal or payment data does not spread into your SIEM. Test each alert once by triggering it on purpose in a non-production environment. Done when the test alerts fire, the on-call runbook names an owner for each one, and the security team confirms that the log flow reaches its central store.
Build the evidence folder
Collect the artifacts from each step into one controlled folder: the counsel memo, the version inventory with its upgrade plan, access review exports, TLS and encryption configuration records, backup schedules, restore test logs, alert test results and incident records. Map each artifact to the NIS2 risk management measure it supports, and use the ENISA technical guidance on evidence examples to check coverage. Assign an owner and a review date to each item. The NIS2 framework has no certificate, so this folder is what you show a competent authority during inspections or information requests. Done when a reviewer outside the platform team can trace every measure to a dated artifact.
Questions buyers ask before hiring help with NIS2 and ClickHouse
Does NIS2 issue a certificate for ClickHouse or for our organization?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your evidence therefore needs to show that risk management measures are in place and operating, such as a documented patching policy on supported ClickHouse versions, access reviews, encryption settings, tested backups and incident detection records. Ask your national authority or legal counsel which obligations apply to your entity, since essential and important entities are supervised differently. DeployOpen prepares systems, controls and evidence for assessments but does not issue certificates or attestations.
What drives the effort of configuring ClickHouse for NIS2?
The main drivers are the scope of the cluster and the number of surrounding systems that must be configured. Expect the effort to grow with:
- Cluster size, including the number of shards, replicas and ClickHouse Keeper nodes, since each one needs its own hardening, monitoring and backup checks.
- Number of identity sources, such as LDAP directories, Kerberos, X.509 certificates, HTTP authenticators or JWT, each requiring its own configuration and testing.
- Number of backup targets, such as local disk, S3-compatible storage or Azure Blob Storage, and the restore tests each one needs.
- Number of environments, since production, pre-production and any restricted network each need consistent controls.
Ask for these inputs to be listed in the written scope so the quote reflects your actual environment.
Can our own team implement these measures without a partner?
Often yes, if the team already runs Linux, networking and database operations, and has someone who can read the ClickHouse documentation carefully. The work spans several skill areas: ClickHouse administration (users, roles, row policies, settings profiles), TLS and certificate management, identity integration, backup and restore engineering, monitoring, and change management for upgrades. The most common gap is restore testing, because the ClickHouse documentation warns that a backup never test-restored will probably not restore properly when needed. Assess each skill against your staff, and decide whether a partner should cover the gaps or only review your design.
How long does a NIS2 ClickHouse engagement take?
Duration depends on the scope agreed in writing, not on a fixed template. The main factors are the number of clusters, the identity and backup integrations, the state of existing documentation and the number of change windows available for testing and production rollout. Your internal approvals and any required pre-production testing also add time. DeployOpen does not give a duration before the scope is defined. Ask for a timeline that lists the phases, the dependencies on your teams and the points where your sign-off is needed.
What do we need to provide during the engagement?
Plan to provide access, named owners and change windows before work starts. Access usually means administrative accounts or a secure session into the environment, in your own cloud accounts, data centers or restricted network. Owners include a database owner, a security contact who approves access policy, an identity owner for LDAP or SSO, and a backup or storage owner. Change windows are needed for rolling upgrades, configuration changes and restore tests on spare clusters. Confirm these items in the written scope, along with who signs off each deliverable.
How does DeployOpen's fixed-scope written quote work?
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from the written scope. The scope should list the environments, cluster components, identity sources, backup targets, controls to be implemented, documentation and evidence to be produced, and the handover. Ask whether the quote separates one-time implementation from recurring items such as ongoing support, upgrades or continuous testing, which are available as retainers. Ask what changes require a new quote.
Which ClickHouse versions should we run to stay supported?
Run only versions that receive security updates. The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as currently supported, and all other versions as unsupported. The production FAQ recommends stable releases for most production use, a pre-production environment with representative data and queries, and reading the changelog before upgrading, because minor backward-incompatible changes can occur. Confirm the current list on the security policy page before you set your patching policy, since support status changes over time.
What a DeployOpen engagement delivers and what you provide
The engagement runs from a written scope through version and access decisions, controls on the cluster, backup and detection work, and a closing evidence pack. Each step names what DeployOpen does, what you provide, and the output that closes it.
Agree scope and NIS2 entity classification
DeployOpen and your team confirm which ClickHouse clusters, environments and data sets fall under your NIS2 obligations, and which national transposition law applies to your entity. Your legal or compliance lead confirms the essential or important classification, because that determines supervision, not the technical work. The output is a written scope with the systems, owners and out-of-scope items listed. The step is done when your signatory accepts that scope in writing.
Inventory versions, exposure and data flows
DeployOpen documents every ClickHouse server, Keeper node, client application, ingestion path and backup target, along with the network paths between them. You provide access to the environments, current configuration files and the names of the people who operate them. The output is an asset and data-flow register, plus a list of the versions in use compared with the versions listed as supported in the ClickHouse security policy. The step closes when your team has reviewed the register for gaps.
Set the patching and upgrade policy
DeployOpen drafts a patching policy that ties your ClickHouse versions to the supported lines in the ClickHouse security policy, and sets a process for reading the changelog before each upgrade, since minor backward-incompatible changes can occur. Your change board approves the policy and the rollback approach. The output is a written patch policy and a tested upgrade runbook for a pre-production environment with representative data. The step closes when a sample upgrade has been rehearsed and signed off.
Harden identity, access and authentication
DeployOpen restricts the default user, moves administration to SQL-driven users and roles, and applies row policies and settings profiles where the data model requires them. Where your directory already exists, DeployOpen connects ClickHouse to it through the external authenticators it supports, such as LDAP, Kerberos, X.509 certificates or JWT, after your identity team confirms the design. You provide the directory owners and the role matrix. The output is a tested access model and a list of accounts with their permissions, which closes the step when the access review matches the approved matrix.
Apply encryption, network and configuration controls
DeployOpen configures TLS for client and inter-node traffic, restricts network exposure to the required paths, and sets up encryption at rest according to your storage platform and key management. Keeper nodes are placed on the hosts your architecture requires. You confirm the certificate authority, key custody and the storage layer, and DeployOpen confirms which settings your environment supports before change. The output is a configuration baseline under version control, and the step closes when a configuration scan against that baseline reports no unexplained deviations.
Build replication and tested backups
DeployOpen sets up ReplicatedMergeTree tables with ClickHouse Keeper, verifies that a recovered replica resyncs from a healthy peer, and configures BACKUP and RESTORE to a target you control. The documentation states that replication alone does not protect against human error or corruption, so backups are scheduled separately. You provide the backup destination, retention requirements and the restore-test environment. The output is a backup job with logs and a documented restore test on a spare cluster, and the step closes only when that restore has completed and the results are recorded.
Enable logging, detection and incident procedures
DeployOpen enables the ClickHouse logs and system tables that record logins and queries, routes them to the log platform you run, and sets alert rules for failed logins, privilege changes, unexpected version drift and replication lag. Your security operations team agrees the escalation path and the reporting roles that NIS2 incident handling requires, while DeployOpen documents the detection use cases. The output is a tested alert set and an incident runbook. The step closes when a simulated event triggers the alert and the runbook is followed to the end.
Hand over the evidence pack and operating model
DeployOpen compiles the configuration baseline, access review, patch records, backup and restore test results, alert tests and runbooks into a single evidence pack, mapped to the control areas in the Article 21 measures and the technical guidance for Implementing Regulation 2024/2690. Your team takes ownership of recurring tasks such as access reviews and restore tests. DeployOpen does not issue a certificate or audit opinion, so you confirm with your competent authority or auditor what they will accept. The output is the pack and a handover session, and the step closes when your owners sign for the operating tasks.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ClickHouse security measures for NIS2, we start from the measures your organization must show, then configure ClickHouse to produce the evidence for them, and leave your team with runbooks and records they can keep up after handover.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which ClickHouse clusters, environments, backup targets and identity sources are covered.
- We confirm which supported ClickHouse version lines your team will run and how upgrades will be tested first.
How we build
- We configure users, roles, row policies and external authentication, and restrict the default user, in your environment.
- We set up TLS, encryption at rest where your storage supports it, and scheduled BACKUP jobs to your chosen target.
- We test restores on a spare cluster and test incident detection rules against the alerts your team will receive.
How we hand over
- You receive configuration, access model documentation, backup and restore runbooks and patching procedures.
- Test results from restore exercises and detection checks are recorded so your team can show them to assessors.
- Handover sessions walk your operators through the procedures they will perform after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
- Retainers can cover tracking of new ClickHouse security releases and planning of upgrades onto supported versions.
- Confirm with DeployOpen what response times and reporting a retainer includes before signing, since these are set in writing.
