Terms of Service: BitHive Reporting Desk
BitHive UG (haftungsbeschränkt), Heisenbergstraße 3, 10587 Berlin, Germany, registered with the commercial register of the Amtsgericht Charlottenburg under HRB 255394 B, represented by its managing director Alireza Khalili ("BitHive", "we").
Version 1.6 · October 2026 · Replaces version 1.5. Main changes: modules and their descriptions (3.2, 3.3a, 3.9, Annex: Module descriptions, version 1.0); "module" in place of "regime module"; the VAT identification number of customers in other EU countries (7.1); no repeated direct debit after a failed, returned or reversed one (7.3 (a)).
1. Scope
1.1 These Terms apply to all contracts under which BitHive provides the BitHive Reporting Desk and related services (the "Service") to a customer (the "Customer").
1.2 The Service is offered exclusively to entrepreneurs within the meaning of Section 14 of the German Civil Code (BGB), legal entities under public law and special funds under public law. It is not offered to consumers. In the order process, the Customer confirms by a separate declaration that it orders for its trade, business or profession. The Customer ensures that the information it gives in the order process is correct and complete, in particular on the conditions in the first sentence of this Section 1.2, its company name, address and VAT identification number and its answers to eligibility questions for modules, and informs BitHive of changes without undue delay. If the conditions in the first sentence are not met, or if a booked module may not be offered to the Customer under the eligibility conditions in its module description (Section 3.9), BitHive may terminate the contract for good cause.
1.3 General terms of the Customer do not apply, even if BitHive does not expressly object to them or performs without reservation. They apply only if BitHive expressly agrees to them in text form.
1.4 Individual agreements (in particular order forms and offers) take precedence over these Terms.
1.5 Seller and payment service provider. BitHive is the seller and issues the invoices to the Customer itself. Payments are processed by the payment service provider named in the order process. The Customer enters its payment details directly with the payment service provider; BitHive does not receive full payment card data. BitHive may change the payment service provider; if the Customer then has to enter its payment details again, BitHive informs it in good time.
2. Conclusion of the contract
2.1 Descriptions and prices on the website are an invitation to submit an order, not a binding offer.
2.2 Online order. The Customer submits a binding order by completing the sign-up and confirming the order in the payment step. Before confirming, the Customer sees a summary of all entries, prices and dates and can correct every entry. The contract is concluded when BitHive confirms the order by e-mail or activates the Customer's account, whichever occurs first. The contract language is English or German, as chosen at sign-up; if the Customer uses the website or the Service in another language, it chooses between English and German at sign-up. BitHive stores the contract text; these Terms and the Data Processing Agreement can be downloaded during the order and are sent to the Customer with the order confirmation.
2.3 Offer. If BitHive makes a written offer, the contract is concluded when the Customer accepts it in text form. Enterprise plans, and modules that the price list marks as available only by offer, cannot be ordered online; they are agreed only by an order form or an offer. Enterprise plans run for at least twelve months and are invoiced annually in advance (Section 7.2); the minimum fee is shown in the price list.
2.4 Free trial.
(a) A company that has not used a trial of the Service before receives a free trial of 14 days. For online orders, a payment method must be provided when the trial starts. Nothing is charged during the trial.
(b) Unless the Customer cancels before the trial ends, the trial converts, without further action by the Customer, into the paid plan, modules and options chosen at sign-up, as last changed by the Customer during the trial, and the first fee is charged at the end of the trial. The Customer is reminded by e-mail at least seven days before the first charge. If the Customer asks for the trial to end early, the paid plan starts and the first fee is charged at that time.
(c) The Customer can cancel during the trial at any time online in its account. The Service then remains available until the end of the trial, and nothing is charged. The contract ends with the trial; Section 8.5 applies.
(d) One trial is available per company. BitHive may identify a company by its VAT identification number or its e-mail domain and may decline a further trial, including where an earlier account of the company has been deleted; the order then starts without a trial, and this is shown before the order is confirmed.
(e) During the trial, BitHive is not liable for slight negligence; Section 10.2 remains unaffected.
(f) On request, BitHive may open a trial without a payment method. The contract is concluded when the Customer accepts these Terms and the Data Processing Agreement on activating the account. Such a trial ends after 14 days without charge and does not convert; (b) and (c) do not apply to it. The Customer continues by ordering the Service online (Section 2.2) or by an order form or offer (Section 2.3). If it does not do so by the end of the trial, the contract ends with the trial; Section 8.5 applies.
3. The Service
3.1 The Service is a software application provided over the internet ("software as a service"). Its functions are described in the service description on the website and in the documentation current at the time of the order. In summary, the Service enables the Customer to:
- upload software bills of materials ("SBOMs") for its products via the web interface or the API;
- have the components listed in the SBOMs automatically compared with vulnerability information from the sources named in the documentation, including information on active exploitation;
- receive notifications when a match is found;
- track the deadlines of reporting obligations, prepare report texts in guided forms for submission by the Customer, and record when the Customer has submitted them;
- document actions and decisions in an audit log.
A "Product" is a product with digital elements that the Customer makes available on the market and creates in the Service under its own name. For each Product, the Service monitors the releases that the Customer marks in the Service as being on the market, up to the number per Product stated in the documentation. Releases do not count towards the product limit of the plan (Section 3.6).
3.2 Nature of the Service. The Service is a technical tool. It does not provide legal advice and does not examine the Customer's individual case. Each module applies the legal rules stated in its module description (Section 3.9 (f)) to the facts the Customer enters, using generic decision aids, deadline calculations and form templates. In particular, BitHive does not decide whether the Customer or its products are subject to a law covered by a module, whether an event is an incident, a significant incident, a personal data breach or a vulnerability within the meaning of that law, or whether, when, to whom and with what content a report or notification must be made. These decisions, the accuracy of the facts entered, and the submission of reports and notifications to authorities, other recipients and affected persons remain the sole responsibility of the Customer. BitHive does not submit reports on the Customer's behalf. The Service does not detect incidents in the Customer's systems; a deadline is calculated only from the times the Customer records.
3.3 Data sources. The results of the Service depend on the completeness and accuracy of the SBOMs provided by the Customer and on the information published by the third-party sources named in the documentation. BitHive processes this information with due care at the interval stated in the documentation (Section 3.8), but has no influence on its content, completeness or timing.
3.3a Legal rules. Each module description states the laws, provisions and, where relevant, Member States its rules cover, and the date of the legal status applied. BitHive monitors these provisions and adapts the rules within a reasonable time after an amendment is published; until then, the module applies the stated legal status and shows it. If an amendment cannot be implemented before it takes effect, BitHive informs the affected Customers in the account and by e-mail. Rules for other Member States or other laws are not owed unless the module description names them.
3.4 BitHive may further develop the Service, in particular adapt it to technical progress, new data sources and legal requirements, provided that the functions agreed in the contract are not materially restricted and the change is reasonable for the Customer. BitHive will announce changes that materially affect the use of the Service at least four weeks in advance in text form.
3.5 BitHive may use subcontractors. It remains responsible for the Service vis-à-vis the Customer.
3.6 Plans, seats and limits. For each module, the booked size (Starter, Team or Business) determines the units stated in its module description (Section 3.6a). Every person with a login to the Customer's account is a seat, whatever the person's role; roles (such as owner, administrator, editor and read-only) determine permissions only, not the price. The Starter, Team and Business sizes include 5, 15 and 30 seats, and Enterprise plans 50 unless the offer states otherwise; the included seats follow from the largest size booked in the account. Each further seat is charged at the price in the price list; more than 500 further seats are available only by offer (Section 2.3). Pending invitations count as seats; deactivated logins do not. A login may be used by one person only. Notifications to channels configured by the Customer, such as Slack, Microsoft Teams or webhooks, need no seat. Technical limits that protect the Service (for example file sizes and upload rates) are set out in the documentation. To protect the Service for all customers, BitHive may limit the number and frequency of requests per account, per API token and per IP address, provided that the limits allow use of the booked plan in the scope described in the documentation. Requests above these limits are rejected with a notice to retry later; this is not a defect. The current limits are published in the documentation.
3.6a Units and true-up.
(a) The module description of each module states the unit in which its size is measured (for example products or legal entities) and how units are counted; add-ons increase the units within the limits stated in the price list. Archived units do not count.
(b) CRA module: each product with digital elements that the Customer, or the manufacturer for which it uses the Service, makes available on the market under its own product name or its own model or type designation is one product. Versions and releases of the same product count as one product. Different products count separately even if they share components or are recorded under one entry in the Service.
(c) The Service does not allow more units to be used than are booked. To use more, the Customer books add-ons or a larger size, which take effect at once (Section 7.6 (a)).
(d) If the units actually in use, counted under the module description, exceed the booked units, in particular because several products are recorded under one entry, or if a login is used by more than one person, BitHive informs the Customer in text form. Within 30 days, the Customer may record the units correctly and reduce them to the booked number, or book the add-ons, size or seats required. Otherwise, BitHive charges the required add-ons, size or seats at the prices in the price list from the first renewal after these 30 days. The Customer may show that fewer units or seats are in use.
3.7 Options. The Customer can book the options published in the price list, in particular further seats, add-ons and extended retention of the audit log and report records. The scope of each option is set out in the price list. A booked retention period applies during the term of the contract. It ends with the contract (Section 8.5) and with the deletion of the account (Section 8.6). Records the Customer needs beyond that must be exported beforehand (Section 6.3).
3.8 Scope of monitoring. BitHive's obligation is to carry out the automated comparison under Section 3.1 with due care at the interval stated in the documentation (currently at least hourly for the sources on active exploitation) against the sources named there, and to hand notifications over to the recipients and channels configured by the Customer. Alerts are sent for each product for which alerts are switched on in the account. A product added while the account has fewer than two active alert contacts starts with alerts switched off, and the account shows this. The Customer decides the alert setting of each product. BitHive changes the interval and the sources named in the documentation only under the conditions of Section 3.4; the interval for the sources on active exploitation will not exceed one hour. The comparison can only identify vulnerabilities that are published in those sources, are attributed there to a matchable component, and concern a component correctly identified in an SBOM of a release that the Customer has marked as being on the market. BitHive does not owe or guarantee that every vulnerability or exploitation report is detected, or that a notification arrives within a particular time, unless the Service Level Agreement expressly designates a time as guaranteed. The Service supports, but does not replace, the Customer's own vulnerability handling and its reporting obligations under Regulation (EU) 2024/2847.
3.9 Modules.
(a) The Service is offered in modules. A module covers one reporting regime, such as the reporting obligations under Regulation (EU) 2024/2847 (the "CRA module"). A function across regimes that can be booked in addition to modules (an add-on function) is not a module; its description in the annex to these Terms applies to it. Each module has its own module description on the website and in the documentation, which sets out its functions, its units and any conditions for booking it.
(b) For each module, the Customer books a size (Starter, Team or Business). The size determines the units stated in the module description. The sizes booked for all modules and the booked options together form the Customer's "plan". Enterprise plans are agreed only by offer (Section 2.3).
(c) The Customer can add a module at any time with effect from the booking; the fee is charged pro rata for the rest of the current billing period (Section 7.6 (a)). The Customer can remove a module with effect from the end of the current billing period (Section 7.6 (b)). Section 7.6 (c) applies to the records of a removed module.
(d) BitHive owes only the modules the Customer has booked, in the scope described at the time of booking; Section 3.4 remains unaffected. BitHive is not obliged to develop or offer further modules; statements about modules that are not yet available are not part of the contract.
(e) BitHive may agree with the Customer on a free trial of a further module; its conditions are stated when the trial is offered.
(f) Each module and the contract notification clocks add-on function are described in a module description published with these Terms. The module description in force when the module is booked forms part of the contract; Section 3.4 applies to later changes. The module description states, in particular: the legal rules and status covered (Section 3.3a); the events, stages, deadlines and recipients the module tracks; the drafts and records it produces; what the Customer must do; and the limits of the module.
(g) Where a module description contains provisions that differ from these Terms, those provisions prevail for that module. The precedence of individual agreements (Section 1.4) and of the Data Processing Agreement in matters of data protection remains unaffected. A module description becomes part of the contract when the Customer books the module.
4. Availability and support
4.1 BitHive provides the Service with the availability and support described in the Service Level Agreement, which forms part of the contract.
4.2 BitHive's performance obligations end at the interface of the data centre to the public internet. BitHive is not responsible for the Customer's internet connection or for disruptions of the public internet.
4.3 A notification counts as delivered by BitHive once it has been accepted for delivery by BitHive's e-mail service provider or by the endpoint of the channel configured by the Customer.
5. Obligations of the Customer
5.1 The Customer shall:
- keep access credentials and API tokens confidential, protect them against misuse and inform BitHive without undue delay if it suspects misuse;
- remove users who no longer need access without undue delay;
- upload SBOMs that reflect its products and supported versions and keep them up to date;
- maintain at least two reachable recipients for notifications and keep their contact details up to date;
- review notifications from the Service without undue delay;
- keep its own copies of the SBOMs it uploads;
- use the Service only in accordance with the contract and applicable law, and in particular not upload malicious code, attempt to circumvent security measures or place excessive load on the Service beyond the limits set out in the documentation.
5.2 The Customer is responsible for all activities carried out with its accounts and API tokens unless it proves that it is not responsible for them.
6. Rights of use and Customer Data
6.1 For the term of the contract, BitHive grants the Customer the non-exclusive, non-transferable right, which cannot be sublicensed, to use the Service for its own business purposes within the scope of the booked plan and options. The Customer may allow its employees and agents acting on its behalf to use the Service within the booked number of seats. The Customer determines the roles and permissions of its users within the Service. Declarations on the contract that the Owner (Section 8.6) or an administrator makes in the account within the functions of their role, in particular orders, changes of plan, modules and options, terminations and the deletion of the account, are made on behalf of the Customer.
6.1a If the Owner is no longer available, the Customer may request in text form that BitHive transfers the Owner role to another user. BitHive transfers the role after it has verified, in particular by a public register and a confirmation through contact details published by the Customer, that the request comes from a person entitled to represent the Customer, has informed the current Owner and the administrators, and has received no objection from a person entitled to represent the Customer within 7 days. BitHive may decline the request if the verification fails.
6.2 All data that the Customer uploads to or creates in the Service ("Customer Data") remains the property of the Customer. The Customer grants BitHive the rights necessary to store and process Customer Data solely for the purpose of providing the Service. BitHive does not use Customer Data for any other purpose, in particular not for training AI models, and does not disclose it to third parties except to subcontractors bound under Section 9.
6.3 The Customer can export its Customer Data at any time during the term in a common machine-readable format.
7. Fees and payment
7.1 The fees result from the order or, if none is agreed there, from the price list published on the website at the time of the order. All prices are net amounts plus value added tax, which is charged as applicable to the Customer. If the Customer has its seat in another Member State of the European Union and provides a valid VAT identification number in the order process, the fees are invoiced without German VAT, the Customer being liable for the VAT (reverse charge).
7.1a Bundle discount. If the Customer books several modules, the discount stated in the price list for the number of booked modules applies to their base prices; it does not apply to seats, add-ons or one-off services. The discount is recalculated whenever a module is added or removed: when a module is added, the new discount applies from that moment, together with the pro-rata charge under Section 7.6 (a); when one is removed at the end of a billing period (Section 7.6 (b)), the discount for the remaining modules applies from the next billing period. A module counts only once it is booked; a trial does not count. If a promotion code applies (Section 7.7) and the Customer adds a module, directly or as a trial, the promotion ends when the addition takes effect; before confirming, the Customer is shown the discount that ends, and from then on the bundle discount under this Section applies. A lower discount resulting from the removal of a module is not a price increase within the meaning of Section 7.4. Changes to the discount levels in the price list apply to existing contracts only under Section 7.4.
7.2 Payment and invoices. Fees are payable in advance for each billing period (monthly or annually). BitHive invoices the fees. If SEPA Direct Debit is offered and the Customer chooses it, the Customer grants BitHive and its payment service provider a SEPA Core Direct Debit mandate. BitHive announces each debit at least two calendar days before it is due; the announcement may be made with the invoice or by the payment service provider. If the Customer has provided a payment method in the order process, BitHive charges each invoice to that payment method when the invoice is issued, the first time at the end of the trial or, without a trial, at the order. Where payment by bank transfer is agreed, in particular for Enterprise plans, one-off services and annual plans from the amount stated in the price list, invoices are due within 14 days of receipt without deduction. If the Customer is in default, BitHive may claim default interest and the flat fee under Section 288 (2) and (5) BGB. BitHive sends invoices by e-mail and makes them available in the account. Where the law allows invoices in a format other than a structured electronic invoice, the Customer agrees to receive invoices in that format, in particular as a PDF file; where the law requires a structured electronic invoice, BitHive issues it in a format complying with the European standard EN 16931.
7.3 Late and failed payments.
(a) A payment is overdue when a charge to the Customer's payment method fails or when an invoice is not paid by its due date. A charge also fails if a direct debit is returned or reversed, unless the debit was not authorised or the invoiced claim did not exist. For a return or reversal the Customer is responsible for, the Customer reimburses the bank and payment-service fees actually charged to BitHive. BitHive retries failed card charges; it does not collect a failed, returned or reversed direct debit again by direct debit. BitHive informs the Customer of an overdue payment by e-mail and in the account, with a link for updating the payment method and with information on how to pay. If the Customer has paid at least once under the contract, the Service continues unchanged for 14 days after the payment became overdue.
(b) From the 15th day after the payment became overdue, or at once if the first charge after a trial fails, the Service is available read-only until the payment is made. Monitoring of existing products, deadlines and notifications continue, and cases that monitoring opens for new matches on existing products continue to be opened. The Customer can record and export reports and other records, export its Customer Data, update its payment method and pay. The Customer cannot itself open new cases, add products, other units or users, upload software bills of materials, change integrations or change its plan (Section 7.6 (f)).
(c) If the payment has not been made 30 days after it became overdue, BitHive may terminate the contract with effect from that day by notice in text form; the subscription then ends. Section 8.5 applies.
(d) If the payment is made before the contract ends, full access is restored without delay.
(e) For invoices payable by bank transfer, (b) and (c) apply only if BitHive has reminded the Customer in text form after the due date.
(f) BitHive's claims to fees that have fallen due, and its further rights, in particular under Section 8.3, remain unaffected.
7.3a Suspension for security reasons. BitHive may block access to the Service in whole or in part, to the extent necessary, if there are concrete indications that accounts or API tokens of the Customer are being misused or that the Customer's use endangers the security or stability of the Service, or if an authority or a court orders it. BitHive informs the Customer without undue delay and, where possible, in advance, and lifts the block as soon as the reason ceases to exist. Notifications about actively exploited vulnerabilities continue to be sent where this is possible without risk to the Service.
7.4 Price changes. BitHive may change the fees for existing contracts with effect from a renewal date, in particular if its costs of providing the Service change (for example for hosting, data sources, third-party services, personnel or payment processing) or if it extends the Service. The new fees are those shown in the price list at the time of the notice. BitHive changes the fees of a contract no more than once in any twelve months. BitHive does not increase the fees of a contract before twelve months have passed since the end of its trial or, if there was no trial, since the start of the contract; fees for upgrades the Customer books (Section 7.6 (a)) are not an increase. BitHive informs the Customer in text form at least 30 days (monthly billing) or 60 days (annual billing) before the renewal date from which the new fees apply, stating the new fees and that date; until then, the previous fees apply. If the fees increase, the Customer may cancel the contract with effect from that renewal date, online in its account or in text form, without observing a notice period; BitHive points out this right in the notice.
7.5 The Customer may only set off claims that are undisputed or have been finally established by a court. This does not apply to counterclaims arising from the same contractual relationship.
7.6 Changes to plan and options. (a) An upgrade (a larger plan, more products, further seats, an additional option or longer retention) takes effect immediately. The difference for the rest of the current billing period is charged pro rata. (b) A downgrade (a smaller size, the removal of a module, fewer seats or add-ons, or shorter retention) takes effect at the end of the current billing period. Persons with a login above the seats included in the smaller size are then charged as further seats unless the Customer deactivates their logins before the change takes effect; the Plan and billing page shows the amount before the Customer confirms the change. A downgrade is possible only if the units in use (Section 3.6a) fit the smaller size together with the add-ons booked for it; the Customer archives any excess units first. (c) A downgrade or the removal of a module does not delete any records. Open obligations of a removed module keep their deadlines and notifications until the Customer closes them, and its records remain available for export within the booked retention period. Only if the Customer shortens the booked retention period are records older than the new period deleted, no earlier than 30 days after the change takes effect; BitHive informs the Customer in advance and gives it the opportunity to export them. (d) A change from monthly to annual billing takes effect immediately: the unused part of the current monthly period is credited, the annual fee is charged at once, and a new annual term begins on that day. A change from annual to monthly billing takes effect at the end of the current annual term. (e) The Customer makes changes on the Plan and billing page in its account, which shows the effect on the price before the Customer confirms. Changes that take effect at the end of a billing period are recorded when confirmed and applied shortly before the renewal; until then, the current plan continues unchanged. Changes confirmed less than three hours before the renewal take effect at the following renewal. If a change confirmed in time is not applied at the renewal, the Customer pays no more than under the changed plan; BitHive credits any difference. (f) While a payment is overdue (Section 7.3), the plan cannot be changed; the Customer can still update its payment method and cancel.
7.7 Promotion codes. A promotion code grants the discount stated with the code, for the duration and under the conditions stated there, in particular its expiry date. Unless stated otherwise, a promotion code can be redeemed once per account and only for an order of a single module on monthly billing; it applies only to the price of that module, starts after any trial, cannot be combined with a bundle discount (Section 7.1a), other promotion codes or annual billing, ends when the Customer changes to annual billing, and has no cash value. If the Customer adds a module while a promotion code applies, the promotion ends under Section 7.1a. BitHive may refuse or withdraw a discount obtained by misuse, in particular by opening several accounts for the same company.
7.8 One-off services. Services outside the subscription are provided only under an order form or offer (Section 2.3); they are not available through the online order. Their scope, fee and dates result from that agreement, and BitHive invoices them (Section 7.2). Fees for a one-off service that has been performed are not refunded unless the order form or offer provides otherwise; statutory rights, in particular in the event of defects, remain unaffected.
7.9 The Refund Policy published on the website applies in addition.
8. Term and termination
8.1 Monthly plans run for one month and renew automatically by one month unless terminated by either party with effect from the end of the current month.
8.2 Annual plans run for twelve months and renew automatically by twelve months unless terminated by either party with one month's notice to the end of the current term. BitHive reminds the Customer by e-mail no later than 45 days before the end of each annual term, stating the renewal date, the fee and the last day for termination.
8.3 The right of both parties to terminate for good cause remains unaffected. Good cause for BitHive exists in particular if the Customer is in default of payment of an amount equal to more than two monthly fees, or seriously breaches Section 5.1 despite a warning.
8.4 Terminations must be made in text form (for example by e-mail to contact@bithive-it.com) or in the account settings.
8.5 After the end of the contract, the Customer can export its Customer Data for 30 days. BitHive then deletes the Customer Data, unless it is obliged by law to retain it; on the Customer's instruction in text form, BitHive deletes it earlier. Backups are overwritten in the regular backup cycle, at the latest 35 days after the deletion. BitHive confirms the deletion in text form on request.
8.6 Deletion of the account.
(a) The user who holds the Owner role in the Customer's account (the "Owner") can delete the account in the account settings or by request in text form to BitHive. Before the deletion is confirmed, BitHive states what will be deleted and what is retained, and offers the export of all Customer Data. The deletion is confirmed in a separate second step.
(b) The deletion takes effect 14 days after this confirmation. Until then, the account is suspended: monitoring and notifications stop, all sessions end, API tokens are no longer accepted, and only the Owner can sign in, to export Customer Data or to cancel the deletion. BitHive informs the Owner and all administrators of the account by e-mail when the deletion is scheduled and three days before it takes effect.
(c) Confirming the deletion is also the Customer's notice of termination. No fees are charged after the confirmation. The contract ends when the deletion takes effect. If the Owner cancels the deletion before it takes effect, the notice of termination is withdrawn and the contract continues. If a billing period has ended in the meantime, the Customer must book a plan again to resume monitoring.
(d) When the deletion takes effect, BitHive deletes all Customer Data, including the audit log and records kept under a booked retention option. Section 8.5 applies accordingly, with the export period of 30 days replaced by the 14 days under (b). Fees already paid are refunded only under the Refund Policy.
(e) BitHive retains its own business records on the contract, such as order, plan-change and cancellation confirmations and the acceptance of these Terms, for the periods required by commercial and tax law. They contain no Customer Data.
9. Data protection and confidentiality
9.1 Insofar as BitHive processes personal data on behalf of the Customer, the parties conclude the Data Processing Agreement provided by BitHive, which forms part of the contract.
9.2 Apart from the delivery of e-mails (next sentence) and of messages to alert channels configured by the Customer, Customer Data is stored and processed exclusively in data centres in Germany. E-mails sent by the Service are delivered by an e-mail service provider in the European Union; details, including any processing by its sub-processors in third countries and the applicable safeguards, are set out in the Data Processing Agreement. E-mails to BitHive's support address are processed in a mailbox hosted in Germany. BitHive will inform the Customer at least four weeks in advance of any change to the storage location.
9.3 Each party shall keep confidential all non-public information of the other party that it obtains in connection with the contract, in particular Customer Data and information about vulnerabilities in the Customer's products, and shall use it only for the purposes of the contract. This obligation continues for three years after the end of the contract and indefinitely for information about vulnerabilities that have not been publicly disclosed. It does not apply to information that is or becomes publicly known without breach of this obligation, that was already known to the receiving party, or that must be disclosed by law or by order of a court or authority.
9.4 The Customer enters payment details directly with BitHive's payment service provider (Section 1.5). The payment service provider processes them on BitHive's behalf to execute payments and, for fraud prevention and to meet its own legal obligations, as an independent controller under its own privacy notice. BitHive does not receive full payment card data.
10. Warranty and liability
10.1 Defects. BitHive warrants that the Service essentially has the agreed functions during the term. The Customer shall report defects without undue delay in text form with a description that allows them to be reproduced. BitHive will remedy defects within a reasonable period. Strict liability for defects that already existed at the time the contract was concluded (Section 536a (1), first alternative BGB) is excluded.
10.2 Liability. BitHive is liable without limitation for damage caused intentionally or through gross negligence, for injury to life, body or health, under the German Product Liability Act, for defects it has fraudulently concealed, and within the scope of any guarantee it has expressly given.
10.3 In cases of slight negligence, BitHive is liable only for the breach of an essential contractual obligation, that is, an obligation whose fulfilment makes the proper performance of the contract possible in the first place and on whose fulfilment the Customer regularly relies (cardinal obligation). In this case, liability is limited to the damage that is foreseeable and typical for this type of contract at the time the contract was concluded.
10.4 In cases of slight negligence, liability for the loss of data is limited to the effort needed to restore it from copies the Customer could reasonably have made, in particular with the export function (Section 6.3). This does not apply to records BitHive must retain under a booked retention option.
10.5 The limitations in this Section 10 also apply in favour of BitHive's employees, representatives and subcontractors.
10.6 In the cases of Section 10.3, BitHive's liability is further limited to EUR 500,000 per damaging event and to EUR 1,000,000 for all damaging events in a contract year. Section 10.2 remains unaffected.
11. Changes to these Terms
11.1 BitHive may amend these Terms with effect for the future if there is a valid reason, in particular changes in the law or case law, or new functions of the Service. BitHive will send the amended Terms to the Customer in text form at least six weeks before they take effect.
11.2 Amendments that affect neither party's main performance obligations and do not shift the balance between performance and fees to the Customer's disadvantage are deemed accepted if the Customer does not object in text form before they take effect; BitHive will point out this consequence in the notice. Other amendments require the Customer's consent. If the Customer objects, either party may terminate the contract with effect from the date on which the amendments would have taken effect.
11.2a For annual plans, amendments take effect at the earliest at the start of the next annual term, unless they are required by a change in the law.
11.3 Changes to the scope of services or the fees are governed exclusively by Sections 3.4 and 7.4.
12. Final provisions
12.1 The Customer may only assign rights under this contract to third parties with BitHive's consent. Section 354a of the German Commercial Code (HGB) remains unaffected.
12.2 BitHive may name the Customer as a reference only with the Customer's prior consent in text form.
12.3 The law of the Federal Republic of Germany applies, excluding the UN Convention on Contracts for the International Sale of Goods.
12.4 If the Customer is a merchant, a legal entity under public law or a special fund under public law, or has no general place of jurisdiction in Germany, the exclusive place of jurisdiction for all disputes arising from this contract is Berlin. BitHive may also sue the Customer at its general place of jurisdiction.
12.5 Should individual provisions of these Terms be or become invalid, the validity of the remaining provisions remains unaffected. The statutory provisions apply in place of the invalid provision.
12.6 These Terms exist in a German and an English version. The version in the contract language is binding. The contract language is German or English: the language chosen at sign-up (Section 2.2) or, for contracts under Section 2.3 and trials opened by BitHive (Section 2.4 (f)), the language of the order form or, if there is none, of the offer, provided it is German or English; in all other cases it is English. Versions of these Terms and of the other contract documents in other languages are provided for information only; they do not form part of the contract, and in case of any difference the version in the contract language prevails.
12.7 Sanctions. The Customer confirms that neither it nor the persons who own or control it are listed under sanctions of the European Union, the United Kingdom or the United States, and that it will not make the Service available to persons or in countries in breach of sanctions or export control law applicable to it. This confirmation is not given, and does not apply, to the extent that giving or complying with it would violate Council Regulation (EC) No 2271/96 or Section 7 of the German Foreign Trade and Payments Ordinance (Außenwirtschaftsverordnung). If the confirmation is or becomes untrue, BitHive may, to the extent permitted under Council Regulation (EC) No 2271/96, suspend access and terminate the contract for good cause.
Annex to the Terms: Module descriptions
Version 1.0 · October 2026 · First version.
This annex contains the module descriptions under Section 3.9 of the Terms for the CRA module, the NIS2 (Germany) module and the GDPR module, and the description of the contract notification clocks add-on function. The add-on function is not a module within the meaning of Section 3.9 of the Terms; it supplements booked modules. The description in force when a module or the add-on function is booked becomes part of the contract; Section 3.4 of the Terms applies to later changes.
1. Common part (applies to every module)
Legal status. In each module, the Service shows the date of the legal status its rules apply (Section 3.3a of the Terms). For the NIS2 (Germany) module and the GDPR module in this version, it is 6 October 2026.
Calculation of deadlines. Deadlines are calculated to the minute from the time the Customer records: hours and days as full 24-hour spans, months to the same calendar day and time. Deadlines are not extended over weekends or public holidays. Where a law does not count the day or hour of the event, or moves a deadline that ends on a weekend or holiday, the statutory deadline may end later than the one shown; the Service shows the earlier time. Where a law requires action "without undue delay", the deadline shown is the latest permissible time, and earlier action may be required.
Anchors. Each deadline runs from a time the Customer records, such as the time of becoming aware, the time of submission of an earlier stage or the date of a request by an authority. For cases the CRA module opens itself, Section 2 applies. The Customer records these times truthfully and without delay. A deadline cannot be calculated before its anchor is recorded.
Legal sources and reminders. Every stage names its legal source, so the Customer can check it. Reminders and target dates that do not reflect a statutory deadline are marked as such in the Service.
Drafts. Drafts follow the structure of the official form or channel named per stage. The Customer checks, completes and submits them itself through that channel. The Service has no connection to authorities' systems.
Alerts. The Service alerts the persons and channels the Customer configures, before each deadline and when it passes, and escalates to a backup recipient where configured (Section 4.3 of the Terms).
Records. The Service keeps a timestamped record of each case, its stages, drafts, recorded submissions and decisions, for the booked retention period (Section 3.7 of the Terms).
Several modules. An incident recorded in the NIS2 (Germany) module or the GDPR module is one case; it opens the stages of each of these booked modules whose conditions the Customer confirms, each with its own deadline, its own recipient and its own draft. CRA module cases are kept per product (Section 2). Personal data from stages of the GDPR module are not carried into drafts of other modules.
Not included. The module does not assess whether a law applies to the Customer or whether an event reaches a legal threshold, and does not submit anything. It does not detect events in the Customer's systems; Section 2 describes when the CRA module opens a case from the sources it evaluates.
Liability. This annex describes the performance. It contains no guarantee and leaves Section 10 of the Terms unaffected.
2. CRA module
Legal rules. Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (1) to (4).
Cases. Each report runs in its own case per product and vulnerability or incident, in the same case list as the other modules:
- (a) an actively exploited vulnerability in a product of the Customer (Article 14 (1) and (2)). If a source the Service evaluates lists a vulnerability in a component from the Customer's SBOMs as actively exploited, the Service opens a case for the product concerned at once. The Service sets the time at which it detected the entry as the time of becoming aware; the Customer can record an earlier time, but not a later one. If the vulnerability is not contained in the product, is not actively exploited, or the product is not subject to the Regulation, the Customer can dismiss the case, stating a reason; the Customer can undo the dismissal. The Customer can also record such a case itself, for example after a notice from a security researcher, a customer or a supplier. If the same product already has an open case for the same CVE or EUVD identifier, the entry is added to that case.
- (b) a severe incident having an impact on the security of a product of the Customer (Article 14 (3) and (4)); the Customer records this case itself.
Stages, case (a) – recipient: the CSIRT designated as coordinator and ENISA, via the single reporting platform (Article 16 of the Regulation).
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Early warning | Becoming aware | Without undue delay, at the latest 24 hours | Article 14 (2)(a) |
| Vulnerability notification | Becoming aware | Without undue delay, at the latest 72 hours | Article 14 (2)(b) |
| Final report | Time, recorded by the Customer, from which a corrective or mitigating measure is available | At the latest 14 days after that time | Article 14 (2)(c) |
Stages, case (b) – recipients as in case (a).
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Early warning | Becoming aware | Without undue delay, at the latest 24 hours | Article 14 (4)(a) |
| Incident notification | Becoming aware | Without undue delay, at the latest 72 hours | Article 14 (4)(b) |
| Final report | Submission of the incident notification | At the latest one month after it | Article 14 (4)(c) |
Limits.
- Whether a product is subject to the Regulation, whether a vulnerability is actively exploited and whether an incident is severe is decided by the Customer (Section 3.2 of the Terms).
- Intermediate reports requested by an authority, and informing the users of the product (Article 14 (8)), are not stages of the module.
- The CRA module does not cover reporting duties under other legislation that the same incident may trigger; the NIS2 (Germany) module and the GDPR module serve that purpose.
3. NIS2 (Germany) module
Legal rules. BSI Act as amended by the NIS2 Implementation Act (BGBl. 2025 I No. 301), in particular §§ 2, 28, 32, 33, 35 BSIG; for profiles (b) to (d) §§ 5c, 5d EnWG, § 168 TKG, Articles 19a and 24 (2)(fb) of Regulation (EU) No 910/2014 (eIDAS Regulation) as amended by Regulation (EU) 2024/1183, and § 2 VDG; Directive (EU) 2022/2555 Article 23 for reference; Implementing Regulation (EU) 2024/2690 for the entity types it covers (significance criteria shown for reference, not evaluated).
Profiles. The Customer chooses one or more profiles in the module: (a) essential and important entities (§ 32 BSIG); (b) energy (§§ 5c, 5d EnWG); (c) public telecommunications networks and services (§ 168 TKG); (d) trust service providers (Articles 19a and 24 (2)(fb) eIDAS Regulation, alongside § 32 BSIG).
Scope self-check. A generic questionnaire on § 28 BSIG (sector per Annex 1 or 2, size per § 28 (1)–(4), size-independent entity types, exceptions under § 28 (5) to (7)). Exceptions under § 28 (5) lead to the energy or telecommunications profile. If the Customer states that it is a financial entity within the meaning of Article 2 (2) of Regulation (EU) 2022/2554 (§ 28 (6) BSIG), the module shows the note "Incident reporting under DORA (Art. 19) applies; this module does not cover it." and no stages under §§ 32 and 35 BSIG; the registration reminder under § 33 BSIG remains available. If the Customer states that it is gematik or a provider of services of the telematics infrastructure (§ 28 (6) no. 2 BSIG), the module shows that the BSIG's reporting duties do not apply and that the duties applying instead are not covered. The result reads "Orientation only; not a legal assessment"; the Customer decides which duties apply.
Stages, profile (a) – recipient: the joint BSI/BBK reporting office via the BSI-Portal; before registration, the online form in the reporting and information portal (MIP).
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Early warning | Becoming aware | Without undue delay, at the latest 24 hours | § 32 (1) sentence 1 no. 1 BSIG |
| Notification | Becoming aware | Without undue delay, at the latest 72 hours | § 32 (1) sentence 1 no. 2 BSIG |
| Intermediate report | BSI request | By the date the Customer records from the request | § 32 (1) sentence 1 no. 3 BSIG |
| Final report | Submission of the notification (no. 2) | At the latest one month after submission of the notification; also shown: conservative target date one month after the early warning (not a statutory deadline); alerts follow the target date | § 32 (1) sentence 1 no. 4 BSIG |
| Progress report | Incident still ongoing when the final-report deadline ends | At the end of the final-report deadline, with the same target date; the final report follows after handling of the incident is completed, with no statutory deadline | § 32 (2) BSIG |
| Information of service recipients | BSI order | Without undue delay | § 35 (1) BSIG |
| Information on significant cyber threats | Significant cyber threat; only for entities in the sectors finance, social security and basic income support for jobseekers, digital infrastructure including managed service providers and managed security service providers, and providers of digital services, unless § 28 (5) or (6) BSIG applies | Without undue delay; recipients: the potentially affected recipients of the services and the BSI; the Customer makes the balancing of interests under § 35 (2) sentence 3 BSIG | § 35 (2) BSIG |
| Registration | Time, recorded by the Customer, from which the entity first or again qualifies as an entity | Reminder: at the latest three months; changes without undue delay, at the latest two weeks after becoming aware of the change | § 33 (1) and (5) BSIG |
Stages, profile (b) energy – recipient: the reporting office under § 32 BSIG (BSI-Portal).
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Early warning | Becoming aware | Without undue delay, at the latest 24 hours | § 5d (3) sentence 1 no. 1 EnWG |
| Notification | Becoming aware | Without undue delay, at the latest 72 hours, including indicators of compromise | § 5d (3) sentence 1 no. 2 EnWG |
| Intermediate report | BSI request | By the date the Customer records | § 5d (3) sentence 1 no. 3 EnWG |
| Final report | Submission of the notification (no. 2) | At the latest one month after submission of the notification; conservative target date and alerts as in profile (a) | § 5d (3) sentence 1 no. 4 EnWG |
| Progress report and later final report | Incident still ongoing | As in profile (a) | § 5d (3) sentence 2 EnWG with § 32 (2) BSIG |
Stages, profile (c) telecommunications – recipients: Bundesnetzagentur and BSI, by e-mail with the PDF form; encryption recommended.
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Early warning | Becoming aware | Without undue delay, at the latest 24 hours | § 168 (1) no. 1 TKG |
| Notification | Becoming aware | Without undue delay, at the latest 72 hours | § 168 (1) no. 2 TKG |
| Intermediate report | Request of the Bundesnetzagentur or the BSI | By the date the Customer records | § 168 (1) no. 3 TKG |
| Final report | Submission of the notification (no. 2) | At the latest one month after submission of the notification | § 168 (1) no. 4 TKG |
| Progress report; final report after completion of handling | Incident still ongoing | At the end of the final-report deadline; then within one month after completion of handling | § 168 (2) TKG |
| Detailed report | Demand of the Bundesnetzagentur | By the date the Customer records | § 168 (4) sentence 2 TKG |
| Public information | Order of the Bundesnetzagentur | As ordered | § 168 (6) sentence 2 TKG |
| Information of potentially affected users | Particular and significant risk of a security incident | No statutory deadline; shown as a task without a deadline | § 168 (7) TKG |
Stages, profile (d) trust services – recipients: the supervisory body (the BSI for certificates for website authentication, the Bundesnetzagentur for the other trust services; § 2 (1) VDG), identifiable affected individuals and the public (non-qualified providers: if it is of public interest; qualified providers: at the request of the supervisory body). The channel is recorded by the Customer. If the incident is also a significant incident, the stages of profile (a) apply in addition, because trust service providers are entities under § 28 BSIG; if it affects personal data, Articles 33 and 34 GDPR apply in addition, which the GDPR module covers where booked. These reports are made separately; no authority is assumed to forward them.
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Notification (non-qualified provider) | Becoming aware | Without undue delay, at the latest 24 hours | Article 19a (1)(b) eIDAS Regulation |
| Notification (qualified provider) | Occurrence of the incident | Without undue delay, at the latest 24 hours after occurrence; while the time of occurrence is not recorded, the Service shows the deadline from becoming aware only provisionally, with the note "The 24-hour period runs from the incident, not from awareness. Record the time of the incident; until then the date shown is provisional and may be later than the legal deadline.", and alerts all configured recipients at once | Article 24 (2)(fb) eIDAS Regulation |
| Public information (qualified provider) | Request of the supervisory body | As requested | Article 24 (2)(fb) eIDAS Regulation |
Free-text fields of this profile carry the hint: "Name no individual person."
Limits.
- This module covers Germany only; other Member States are not covered.
- The Service has no connection to the BSI-Portal or other reporting channels; the module keeps its own copy of the Customer's drafts and recorded submissions.
- Registration itself (§ 33 BSIG) is done by the Customer in the BSI-Portal; the login uses "Mein Unternehmenskonto" with an ELSTER organisation certificate.
- The module does not assess whether a security incident is significant; the criteria are shown for reference.
4. GDPR module (personal data breaches)
Legal rules. GDPR Articles 4 (12), 33 and 34; BDSG § 29 (1) and §§ 42 (4), 43 (4) (shown as notes); § 169 TKG with Regulation (EU) No 611/2013 (telecommunications profile).
Modes. The module includes both modes in every size; the Customer chooses the mode per case.
Controller (the Customer is the controller):
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Notification to the competent supervisory authority | Becoming aware | Without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk; if later, with a field for the reasons for the delay (Article 33 (1) sentence 2 GDPR) | Article 33 (1) GDPR |
| Content | – | Nature of the breach with categories and approximate number of data subjects and records; contact point; likely consequences; measures | Article 33 (3) GDPR |
| Supplements | Earlier submission | Without undue further delay; reminder after 14 days (BitHive default; no legal or authority deadline) | Article 33 (4) GDPR |
| Communication to data subjects | Customer's decision that there is a high risk | Without undue delay; reminders after 24 and 72 hours (not statutory deadlines); exceptions under Article 34 (3) GDPR as a checklist; under the exception in Article 34 (3)(c) GDPR, a public communication takes the place of the communication to data subjects; confidentiality exception under § 29 (1) BDSG as a note | Article 34 (1) and (2) GDPR |
| Communication ordered by the supervisory authority | Order | As ordered | Article 34 (4) GDPR |
| Documentation | Every breach, including those not notified | Ongoing | Article 33 (5) GDPR |
The module shows the channel of the supervisory authority the Customer has recorded as competent for the entity concerned (the authority of the German Land or the BfDI), where the Service holds a channel for that authority. Where it holds none, the Customer takes the channel from the authority's website.
Processor (the Customer processes personal data on behalf of its own customers):
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| Notification to each affected controller | Becoming aware | Without undue delay; reminders after 24 and 72 hours (not statutory deadlines) | Article 33 (2) GDPR |
The module drafts the notification with the information under Article 33 (3) GDPR that the controller needs, and records when each controller was informed. The Customer's controllers decide on notifying the supervisory authority and data subjects. Shorter deadlines from the Customer's contracts with its controllers are recorded by the Customer with the contract notification clocks add-on function (Section 5).
Telecommunications profile (providers of publicly available telecommunications services):
| Stage | Anchor | Deadline | Legal source |
|---|---|---|---|
| First notification to the Bundesnetzagentur and the BfDI | Detection | Without undue delay, where feasible within 24 hours | § 169 (1) sentence 1 TKG; Article 2 (2) Regulation (EU) No 611/2013 |
| Second notification | First notification | At the latest three days later | Article 2 (3) first subparagraph Regulation (EU) No 611/2013 |
| Remaining information | Second notification | As soon as possible, with reasons | Article 2 (3) second subparagraph Regulation (EU) No 611/2013 |
| Notification of subscribers and affected individuals | Detection | Without undue delay, whether or not the authorities have been notified; as a decision aid, both thresholds: likely to adversely affect (Article 3 (1) of the Regulation) and seriously impaired (§ 169 (1) sentence 2 TKG); exception for unintelligible data as a checklist | § 169 (1) sentences 2 and 3 TKG; Articles 3, 4 Regulation (EU) No 611/2013 |
| Notification ordered by the Bundesnetzagentur | Order | As ordered | § 169 (1) sentence 4 TKG |
| Inventory of breaches | Every breach | Ongoing | § 169 (3) TKG |
Data minimisation. The module records categories and approximate numbers of data subjects and records, not their identities. Free-text fields carry the hint: "Name no individual person."
Limits.
- The module does not assess the risk to data subjects; the risk questions are a checklist the Customer answers.
- The Customer records which supervisory authority is competent for each entity; the module does not determine it. Cross-border cases with a lead supervisory authority (Article 56 GDPR) are shown as a note, not resolved.
- Channels are stored only for German supervisory authorities. For other Member States the stages of Article 33 GDPR apply, and the Customer records the channel.
5. Contract notification clocks (add-on function)
Content. The Customer records notification duties from its own contracts (for example DPA clauses, SLA notices or customer contracts that require incident notice within a set time, including clauses agreed with customers in the financial sector). For each duty it records:
- the counterparty;
- the triggering event as defined in its contract;
- the anchor;
- the deadline in hours or calendar days;
- the recipient and channel.
The Service calculates the deadlines from the recorded anchor, alerts and escalates, drafts the notification from the Customer's template, and records when it was sent.
Limits.
- BitHive does not read, interpret or check the Customer's contracts. The rules apply exactly as the Customer records them.
- Deadlines are calculated in hours or calendar days from the recorded time, without extension over weekends or public holidays. Where the contract counts business days, the Customer records a period equal to the earliest possible end of that deadline.
- The add-on function does not make BitHive a party to the Customer's contracts with financial entities, or an ICT third-party service provider under those contracts. BitHive's contract with the Customer is the Terms only.