HinSchG for IT Providers + MSSPs: Specifics

Further reading: HinSchG: Setting up an internal reporting channel — how to set up the internal reporting channel under the HinSchG step by step, with a checklist.

1. Dual regulation: NIS2 + HinSchG

IT service providers and MSSPs are subject to two sets of rules with separate triggers: whistleblower protection is in principle tied to the number of employees, whereas NIS2 is tied first to the type of entity under the sector annexes and only then to size. IT service providers are often within the scope of NIS2 (cloud, managed services). The HinSchG applies in addition where there are, as a rule, 50 or more employees.

In Austria, § 3(1) in conjunction with § 11(1) HSchG requires the same from 50 employees. The annex and turnover are irrelevant to this obligation; the sector matters only within the framework of § 12(3) HinSchG — for the employers listed there, the obligation applies irrespective of the number of employees. These include, among others, investment services firms, stock exchange operators, institutions under the German Banking Act (KWG) and the German Securities Institutions Act, capital management companies, insurance undertakings as well as crypto and payment service institutions; an IT service provider that also falls into one of these categories needs the reporting channel from its first employee onwards.

By contrast, in Germany NIS2 as a rule only applies to companies once a type under the annexes to the BSIG is present (federal administration entities are covered separately under § 29 BSIG); in addition, operators of critical installations are deemed particularly important entities irrespective of this (§ 28(1) BSIG). Relevant for IT service providers are the management of ICT services (managed services) under Annex 1 BSIG as well as digital service providers under Annex 2 BSIG. Irrespective of size, Germany treats, among others, operators of critical installations, qualified trust service providers, top-level domain name registries and DNS service providers as particularly important entities (§ 28(1) BSIG); § 28(2) BSIG additionally counts trust service providers among the important entities, in so far as they are not already particularly important entities — a small trust service provider is therefore not excluded merely because it does not reach the size thresholds in the table below. Providers of publicly available telecommunications services and operators of public telecommunications networks are subject to their own classification rules (§ 28(1) no. 3 and (2) no. 2 BSIG). In Austria, qualified trust service providers, TLD name registries and DNS service providers are essential entities irrespective of size, and telecommunications and trust service providers are important entities irrespective of size, provided they are not already essential entities (§ 24(1) and (2) Austrian Network and Information Systems Security Act 2026 (NISG 2026)).

The table sets out size-dependent thresholds only; the size-independent NIS2 cases are in the paragraph above. For determining size, Recommendation 2003/361/EC applies, with the exception of Art. 3(4) of its annex (§ 28(4) BSIG; § 25 NISG 2026).

2. Client confidentiality: what a report changes about confidentiality duties

Client and customer data remain protected — a report does not lift confidentiality duties across the board, but conversely confidentiality clauses cannot contract out of whistleblower protection. The whistleblower may report security vulnerabilities; whether passing on the information is protected is decided under § 35 HinSchG by whether there was sufficient reason to believe it was necessary to reveal a breach — that same standard also governs to whom client names may be disclosed.

Legally, this rests on two provisions. First, § 35 HinSchG: responsibility for obtaining the information is excluded only as long as obtaining it does not itself constitute a separate criminal offence. In Austria, § 22(1) and (2) HSchG governs freedom from liability for the consequences of a justified report: a justified report given in accordance with the procedure does not breach any confidentiality obligations, in so far as there was sufficient reason to believe that it was necessary to reveal or prevent a legal violation. Second, § 39 HinSchG: agreements that restrict the rights of whistleblowers are void — this also applies to confidentiality clauses in employment contracts, client contracts or data processing agreements.

The material scope differs: in Germany, § 2(1) nos. 1 to 3 HinSchG covers all breaches subject to criminal penalties, breaches subject to administrative fines in so far as the provision infringed serves to protect life, limb or health or to protect the rights of employees or their representative bodies, as well as numerous enumerated legal provisions. Austria is narrower: § 3(3) HSchG names the EU areas including data protection plus the corruption offences under §§ 302 to 309 of the Austrian Criminal Code (StGB).

Practical recommendation (not a legal obligation): separate the reporting form and the case file so that client names are recorded only within the protected procedure and do not end up in general ticketing systems. For handling client details within the report itself:

• as a rule use a system identifier, client ID or contract number instead of the client name;
• the client name only where clarification is impossible without it — the standard remains necessity under § 35 HinSchG;
• do not attach raw data (logs, screenshots from client systems) to the report, but secure them in the target system and reference them;
• where a report is made to the external reporting channel, the same standard applies, and § 39 HinSchG prevents any contractual restriction.

3. Insider threat or whistleblower: what decides the distinction

The distinction turns on the manner in which the information was obtained and on what the employer can prove. It is difficult in individual cases: anyone who copies data may be committing an offence; anyone who reports vulnerabilities is a whistleblower.

On the acquisition side, § 35 HinSchG applies (section 2): protection does not apply where obtaining the information as such constitutes a separate criminal offence. On the response side, § 36(1) HinSchG applies — reprisals, including threatening and attempting them, are prohibited — and § 36(2) HinSchG: if the whistleblower suffers a detriment and asserts that they suffered it as a result of the report, a reprisal is presumed; the party causing the detriment must then prove that the detriment was based on sufficiently justified grounds or was not based on the report. On the differing Austrian standard — prima facie evidence under § 23 HSchG instead of a full reversal of the burden of proof — see the FAQ at the end of the article.

Conversely, the law protects the employer against knowingly false reports: § 38 HinSchG establishes a right to damages for intentionally or grossly negligently incorrect reports, and under § 9(1) HinSchG identity protection does not apply in such cases. The Lower Saxony Regional Labour Court (LAG Niedersachsen) confirmed the two-stage test in its judgment of 11 November 2024 (7 SLa 306/24). Practical recommendation (not a legal obligation): document proof of independence for every HR measure taken after a report. This should include the date and occasion of the measure, the person deciding, evidence that the process had already been initiated before the report was received, and an identity-free reference to the reporting process instead of personal data; the record is filed outside the reporting channel's case file so that the access limits of § 8(1) HinSchG are preserved.

Technically, NIS2 flanks this risk: access control, multi-factor authentication and personnel security are part of the statutory minimum catalogue of risk management measures (§ 30(2) BSIG; Austria § 32(4) NISG 2026) — the full catalogue and the documentation obligation of § 30(1) BSIG are in section 6. Privileged access management is the widely used practical implementation of this requirement, not its statutory wording. Practical recommendation (not a legal obligation): log privileged sessions in such a way that, after a report, it can still be traced who accessed what and when — this is the basis for the proof of independence above. In concrete terms this concerns the roles with client admin access in the SOC; what is logged is identity, time window and target system, not content from reports. For the retention period, aligning with the deletion periods of the reporting channel is a sensible option — three years in Germany, five years in Austria, references in section 7.

4. Escalating an incident to the client: which deadline runs when

A report about a security vulnerability at a client may trigger several deadlines — each with its own trigger: the HinSchG deadlines from receipt of the report (7 days for the acknowledgement of receipt) or from confirmation of receipt (3 months for feedback; in Austria from acceptance of the report), the NIS2 deadline only where there is a significant security incident, running from knowledge of it, and the GDPR deadline for the controller from knowledge of a personal data breach. Where there is a report about a security vulnerability at a client, the client must be informed; the basis is the data processing agreement under Art. 28 GDPR (minimum content see section 6).

Each row has its own trigger: the NIS2 deadlines run only where there is a significant security incident within the meaning of § 2 no. 11 BSIG or § 35(1) NISG 2026 — that is, in the case of serious operational disruption or financial loss for the entity, or considerable damage to third parties. The GDPR deadlines are addressed to the controller, which in an MSSP relationship is regularly the client. The HinSchG deadlines continue to run in-house independently of this.

Sorted by time, the same case — a SOC employee reports a vulnerability that affects a client — produces the following sequence; the references are in each case in the table above. Steps 4, 5 and 7 concern only the entity at which the significant security incident occurred, and only if it is a particularly important or important entity (AT: essential or important entity); where the incident affects the client's systems, the NIS2 reporting obligation falls on the client.

1. T+0: the report is received by the internal reporting channel; establish confidentiality under § 8(1) HinSchG (Austria: § 7(1) and (2) HSchG).
2. T+0: first check whether your own company is an entity under section 1 at all — if not, steps 4, 5 and 7 do not apply; then check whether there is a significant security incident under § 2 no. 11 BSIG (Austria: § 35(1) NISG 2026) — only this classification starts the NIS2 clock.
3. Without undue delay: inform the recipients of the services and notify the client as controller — in an MSSP relationship via Art. 28 and Art. 33(2) GDPR in conjunction with the data processing agreement.
4. T+24 hours: early initial report to the joint reporting office of the BSI and the BBK — Austria: early warning to the competent CSIRT.
5. T+72 hours: report with initial assessment.
6. T+7 days: acknowledgement of receipt to the whistleblower.
7. T+1 month after the 72-hour report: final report, in Austria the final account.
8. T+3 months: feedback on follow-up measures to the whistleblower — in Germany the deadline runs from confirmation of receipt, in Austria from acceptance of the report.

Without an NIS2 obligation of your own, what remains are the HinSchG deadlines (steps 1, 6, 8) and the data processing agreement chain towards the client (step 3) — the MSSP then owes the onward information to the client contractually, not under supervisory law (section 6).

5. Protection of SOC staff: roles, right to choose, fine framework

SOC staff are whistleblowers like all other employees — protected by §§ 8, 35 and 36 HinSchG, in so far as the report falls within the material scope of § 2(1) HinSchG (Austria narrower: § 3(3) HSchG).

They may choose whether to turn to the internal or to an external reporting channel; internal reporting should be preferred where the matter can be effectively remedied internally and no reprisals are to be feared (§ 7(1) HinSchG). Obstructing reports, or attempting to do so, is prohibited (§ 7(2) HinSchG). The federal external reporting channel is the Federal Office of Justice (BfJ) (§ 19(1) HinSchG), and in Austria the Federal Bureau of Anti-Corruption (BAK) (§ 15(1) HSchG), in so far as no special external reporting channel is competent (in Germany, among others, BaFin under § 21 and the Federal Cartel Office (Bundeskartellamt) under § 22 HinSchG; in Austria, among others, the FMA and the Federal Competition Authority (Bundeswettbewerbsbehörde) under § 15(2) HSchG). For identity protection under § 8(1) HinSchG, the access limits from section 7 apply. Where the report concerns a vulnerability at a client rather than your own operations, the procedure from section 4 applies in addition.

The sanctions are shaped differently in the two jurisdictions. In Germany, § 40 HinSchG penalises the obstruction of a report and reprisals (para. 2 nos. 1 and 3) as well as intentional or reckless breaches of confidentiality (para. 3) with up to EUR 50,000, the absence of an internal reporting channel (para. 2 no. 2) with up to EUR 20,000 and negligent breaches of confidentiality (para. 4) with up to EUR 10,000 (§ 40(6) sentence 1 HinSchG); for legal persons, a tenfold increase up to EUR 500,000 is possible via § 30(2) sentence 3 of the German Act on Regulatory Offences (OWiG) — expressly not for the offence of failing to establish a reporting channel (§ 40(6) sentence 2 HinSchG). In Austria, the district administrative authority (Bezirksverwaltungsbehörde) imposes administrative fines of up to EUR 20,000, and up to EUR 40,000 in the event of a repeat offence (§ 24 HSchG).

What is specific to the SOC is above all the conflict of roles: whoever handles a report decides on follow-up measures against colleagues on the same shift — and on access rights that they themselves need operationally. § 15(2) HinSchG separately requires the necessary expertise; according to the practical standard for reporting channel training, it should cover the procedure, confidentiality, the GDPR interface, protection against reprisals and the investigation of facts — the provision does not require legal training. Practical recommendation (not a legal obligation): do not staff the reporting channel from the SOC line, and document the declaration of independence of the person appointed. Anyone unable to find a conflict-free appointment in-house may transfer the tasks of the reporting channel to a third party — conditions and limits in section 7. A second fallback remains the right to choose under § 7(1) HinSchG: the external reporting channel is the way out for SOC staff where the internal body sits within their own line.

6. NIS2 supply chain: Section 30 BSIG in MSSP contracts

Supply chain security is part of the statutory minimum catalogue of risk management measures — the practical consequence: NIS2 requirements reach the MSSP via client contracts, even if it is itself below the thresholds. § 30(1) BSIG obliges particularly important and important entities to take appropriate, proportionate and effective technical and organisational measures and to document them; § 30(2) nos. 1 to 10 BSIG names the mandatory areas, including supply chain security, incident handling, business continuity, cryptography, access control and multi-factor authentication. In Austria, § 32(1) and (4) NISG 2026 corresponds to this, and under Union law Art. 21(1) and (2) NIS2 Directive.

What this means for the contract can be derived from the catalogue. The following overview assigns to each typical contractual requirement its statutory anchor on the client's side and states what the MSSP must deliver for it; where no legal provision stands behind it, the row is expressly marked as a practical recommendation:

Responsibility lies at the top: the management bodies of particularly important and important entities must implement the measures under Section 30 BSIG and monitor their implementation; if they breach these duties, they are liable to their entity (§ 38(1) to (3) BSIG). In Austria, the management bodies must ensure and supervise compliance with the risk management measures under § 32 NISG 2026 (§ 31(1) and (2) NISG 2026) — details in the FAQ.

On evidence, DE and AT diverge — the difference belongs in every contract negotiation with Austrian clients:

7. Synchronising the § 8 HinSchG confidentiality concept and the data processing agreement

The reporting channel's confidentiality concept and the data processing agreement clauses towards clients must describe the same access limits — otherwise one promises what the other excludes. § 8(1) HinSchG requires the identity of the whistleblower, of the persons concerned and of other persons named in the report to be protected; access is available only to the persons responsible for receiving reports and taking follow-up measures and to the persons supporting them. Austria governs this in § 7(1) and (2) HSchG and additionally prohibits onward disclosure by persons who have learned the content without authorisation.

If the reporting channel runs on a service provider's IT systems, a data processing agreement under Art. 28(1) and (3) GDPR is required. In addition, an entry in the record of processing activities, a reporting-channel-specific technical and organisational measures concept and data protection information for whistleblowers and accused persons are needed. The data protection impact assessment under Art. 35 GDPR must be carried out in Germany: according to the guidance of the German Data Protection Conference (Datenschutzkonferenz, DSK) on whistleblowing hotlines (14 November 2018, section E 9), a procedure for reporting wrongdoing is subject to a data protection impact assessment because of the particularly high risk to the rights and freedoms of natural persons. In Austria it is dispensable under § 8(13) HSchG.

Synchronising means, in concrete terms: reconciling the four points at which a standard data processing agreement clause runs counter to § 8 HinSchG. The resolutions in the right-hand column are practical recommendations, not legal obligations:

Retention and limitation periods should match: the limitation period for prosecution is three years for the offences carrying EUR 50,000 and EUR 20,000 (§ 31(2) no. 1 OWiG), and only two years for negligent breaches of confidentiality (§ 31(2) no. 2 OWiG) — the German three-year deletion period from the table above therefore covers both limitation periods. If an accused person requests access under Art. 15 GDPR, the established route in Germany is a redacted response with deferral under § 29 of the German Federal Data Protection Act (BDSG): (1) observe the response deadline — Art. 12(3) GDPR; (2) redact the identity of the whistleblower and any details that would allow conclusions to be drawn about them — § 8(1) HinSchG takes precedence over the right of access; (3) document the deferral and its reason in the case file. This article makes no statement for Austria.

The tasks of the internal reporting channel may be transferred to a third party (§ 14(1) sentence 1 HinSchG); the duty to take appropriate measures to remedy a breach remains with the employer (§ 14(1) sentence 2 HinSchG). The European Commission is not pursuing infringement proceedings against Germany in respect of § 14 HinSchG; proceedings INFR(2022)0052 concerning Directive (EU) 2019/1937 ended with the CJEU judgment C-149/23 of 6 March 2025 (lump sum of EUR 34 million) and were closed on 4 June 2026 (as at: 17 August 2026). Whether the group outsourcing solution of § 14 HinSchG satisfies the Directive's linkage to the legal person in every constellation has not been clarified by the courts. Practical recommendation (not a legal obligation): use a hybrid model (the subsidiary's own reporting channel plus the group body as a third party) rather than pure group outsourcing, and provide for an adjustment or termination clause in the outsourcing contract in case the law changes.