C5 domain INQ: handling investigation requests from government agencies in an auditable way

This page covers the INQ domain (Dealing with Investigation Requests from Government Agencies) of C5:2026, section 5.16 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue. This page describes which procedures the catalogue requires; whether an individual request is lawful is assessed by your legal department or a law firm you engage.

What is the INQ domain about?

INQ is meant to ensure appropriate handling of investigation requests from government agencies, and the catalogue names three building blocks: legal review, information to customers and limitation of access to or disclosure of customer data or cloud service derived data (objective in section 5.16). In searches, such requests also appear as “government data requests” or “law enforcement requests”; the catalogue does not use these words as terms. They include, for example, requests from law enforcement agencies or intelligence services; according to the notes on GC-05, which bodies these are and on what basis they act differs from country to country.

The domain comprises four criteria, INQ-01 to INQ-04, with 8 basic subcriteria and 2 complementing additional subcriteria. According to the BSI change history, the former criteria INQ-01 and INQ-03 from C5:2020 have been merged into INQ-01, and the former INQ-04 is now called INQ-03. INQ-04 is new: the provider documents the technical procedures with which it provides or discloses customer data in response to such requests and makes them available to its customers.

Closely related is the general condition GC-05: there the provider describes in the system description how it handles such requests and states the number of requests and their countries of origin, see General conditions. INQ contains the controls, GC-05 the information about them.

Starting point: a SaaS provider without a process for government requests

Fictitious example, not a client. A provider runs a whistleblowing system as SaaS for companies and municipalities: whistleblowers report violations via a web form, anonymously if they wish, and the customer’s reporting office processes the reports in the service. The service runs in a German region of a large cloud service provider. The reports are stored in encrypted form; the provider manages the keys.

Before the project, the situation looks like this:

• Last year a public prosecutor’s office asked support by email for the data on a specific report. Support asked management, and management asked a lawyer friend.
• Whether and when the affected customer was informed is not documented.
• For the disclosure, a developer pulled a database extract that contained more fields than requested.
• Customers ask in security questionnaires whether the provider can decrypt reports. There is no agreed answer.

For the audit, the provider needs a process that treats every request the same way, including those that do not lead to a disclosure.

Who is responsible for what: provider, platform, customer?

INQ lies with the provider, but the customer has to include the risks in its own risk management. The platform in the example is a subservice organisation. Our classification for the example:

INQ-01, INQ-02 and INQ-04 contain complementary customer criteria, INQ-03 does not. Whichever customer controls you assume belong in the system description as complementary customer controls (CUEC). The auditor does not test them at the customer, only whether they are fairly presented.

What does a process for government requests look like?

You write the process as a work instruction known to everyone a request may reach: support, sales, management. For the example it could look like this (own proposal, not catalogue text):

The four-eyes principle and the dedicated account are our recommendation. According to the supplementary information, the obligation under INQ-02 to inform without undue delay does not affect other legal or regulatory requirements that require customers to be informed earlier.

What belongs in the disclosure under INQ-04?

INQ-04.02B names six minimum aspects that the document for customers addresses: the process for provision and disclosure, the provider’s technical capabilities and limitations, the logging of such access, the customers’ possibilities to review these logs, the methods per service and the legal means that can restrict informing customers. According to the supplementary information, the criterion is limited to customer data. For the example, this above all means answering the question from the questionnaires honestly: the provider manages the keys and can therefore in principle decrypt reports. If you want to change that, consider procedures with customer-managed keys, see CRY; the disclosure then describes the new state. The document is maintained in accordance with SP-01 and aligned with the guidelines on minimising access to customer data (INQ-04.03B).

Example control description for INQ-01

INQ-01 is the core of the domain: every investigation request from a government agency for customer data, cloud service derived data and account data is subject to a documented legal assessment by subject matter experts (INQ-01.01B), and access or disclosure is only permitted if this assessment confirms an applicable and valid legal basis and that the request must be granted (INQ-01.02B). Our example control for the provider above (own wording, not catalogue text):

Whether the control covers all subcriteria is for the auditor to assess; for a type 2 report the auditor also tests whether it operated effectively throughout the period.

What evidence the auditor wants to see

The catalogue expressly defines the population for the audit: all investigation requests that were completely processed during the period, irrespective of whether they resulted in a disclosure (supplementary information on INQ-01.01B). A complete register is therefore the most important evidence. Examples from our scenario:

An evidence register records which evidence belongs to which subcriterion; how to maintain one is shown on the page Evidence and documentation.

Possible gaps: cause, effect, remedy

The following gaps follow from the wording of the criteria and the scenario above. If a single subcriterion is not met, the criterion counts as not met, and the auditor reports the deviation (sections 3.4.12 and 3.4.13).

All criteria of the INQ domain

Titles as in the English version 1.0.1, number of subcriteria counted per section 5 (B = basic, AS = sharpening, AC = complementing). The column “What it covers” is our own short description, not catalogue text; the wording of the criteria in the catalogue is binding.

Both complementing subcriteria belong to INQ-03: the provider monitors access and activities performed by or on behalf of investigators (INQ-03.01AC) and remediates deviations identified during this monitoring in a timely manner (INQ-03.02AC).

Relationship to ISO/IEC 27001:2022 Annex A

There is no direct counterpart to INQ in ISO/IEC 27001. The following mapping is our own, unofficial classification by topic; it only shows where an existing ISMS offers points of contact. The BSI has not yet published a cross-reference for C5:2026. The catalogue refers to the BSI website for it (section 3.3). So far the table there covers C5:2020 only, and the BSI says the table for C5:2026 is “scheduled for publication in the near future” (as of 6 November 2026). The short labels are ours, not titles from the standard.