C5 domain SIM: detecting, handling and reporting security incidents in an auditable way

This page covers the SIM domain (Security Incident Management) of C5:2026, section 5.13 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the SIM domain about?

SIM requires a consistent approach with which the provider captures, evaluates, communicates and handles security incidents (objective in section 5.13). This includes a policy with guidelines on classification, prioritisation, escalation and root-cause analysis, a CSIRT, response plans, informing the affected customers, the personnel’s duty to report and a learning process with a knowledge repository.

The domain comprises six criteria, SIM-01 to SIM-06, with 22 basic subcriteria and 5 complementing additional subcriteria; there are no sharpening ones. SIM-02 on response plans is new. The former criteria SIM-02 to SIM-05 from C5:2020 are therefore now called SIM-03 to SIM-06; map old controls by their topic, not by their number.

Disruptions and crashes without a security dimension are covered by the OPS domain; there, OPS-19 governs when a disruption is passed on as a security incident. The policy under SIM-01.01B expressly creates interfaces to incident management and to business continuity management, see BCM.

Starting point: a SaaS provider with on-call duty but no incident process

Fictitious example, not a client. A provider runs software for processing incoming invoices for medium-sized companies: documents are uploaded, read automatically and passed to accounting in an approval workflow. The service runs on the infrastructure of a large cloud service provider. Around 45 employees, an operations team with on-call duty around the clock, logs flow into a central logging system with alerts.

Before the project, the situation looks like this:

• Alerts end up as disruptions in the ticket system. Whether something is a security incident is decided by the person on call at their own discretion.
• There is no CSIRT. During a suspicious login in the previous year, operations, development and management worked together in a chat channel.
• Customers are informed when sales considers it necessary, by email to the known contact person.
• Logs are overwritten after 30 days; how to secure data of a suspicious system is not described anywhere.
• What was learned from an incident is noted, if at all, in the closing comment of the ticket.

For the audit, the provider needs a defined process that leaves traces for every incident in the period: classification, handling, informing customers, root-cause analysis.

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

SIM is the provider’s responsibility. The platform, in the example a subservice organisation, handles incidents in its own infrastructure according to its own procedure; the customer plays its part in reporting events and receiving notifications. Our classification for the example:

SIM-01, SIM-04, SIM-05 and SIM-06 contain complementary customer criteria, SIM-02 and SIM-03 do not. The customer controls you assume, for example an up-to-date contact address for security notifications, belong in the system description as complementary customer controls (also called complementary user entity controls, CUEC). The auditor does not test them at the customer, only whether they are fairly presented.

How and when do you inform affected customers?

The catalogue requires that customers affected by security incidents are informed “in a timely and appropriate manner”, via communication channels that have been identified and defined beforehand (SIM-01.03B). After processing, the solution is documented in accordance with the contractual agreements and sent to the affected customers (SIM-04.01B); information on security incidents or confirmed security breaches is made available to all affected customers (SIM-04.02B). The SIM domain sets no fixed deadline in hours.

You therefore define yourself what “timely” means for your service: in the contract with the customers and in the policy under SIM-01. We recommend setting the deadline per class of the incident catalogue and naming the channel, for example a security contact address that the customer maintains in the service. If you include the complementing subcriterion SIM-04.02AC, you also regulate in the contract which data the customer receives in the event of an incident for its own analysis.

Statutory reporting obligations, for example under the NIS2 Directive as transposed into national law (see C5 and NIS2) or under DORA in the financial sector (see C5 and DORA), apply independently of these catalogue requirements; whether and with which deadlines they affect your service has to be assessed legally in the individual case. For a type 2 report, significant events in the period, for example unauthorised access by third parties to customer data, also belong in the system description, see Significant changes and events.

Example control description for SIM-03

With seven basic subcriteria, SIM-03 is the most extensive criterion in the domain. It requires that subject matter experts classify and prioritise events that could constitute a security incident and analyse their root cause (SIM-03.01B), that the results are documented, shared and used in the learning process (SIM-03.02B), and that classification is based on a maintained catalogue of incident types, which is also used to correlate events (SIM-03.04B, SIM-03.05B). Documents and evidence on incidents are archived in a secure and tamper-proof manner (SIM-03.06B). Our example control for the provider above (own wording, not catalogue text):

Target times and classes are our example values, not catalogue requirements. 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

For SIM, the evidence comes mainly from the incidents and events in the period. If there was no incident, you evidence the process through the policy, the plans and the handling of events that turned out to be harmless; agree early with the auditor how they will deal with this. 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).

How to put these gaps in order together with those of other domains is shown on the page Prioritising measures.

All criteria of the SIM 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.

The complementing subcriteria of SIM-03 require annual exercises or tests such as Red Team training (SIM-03.01AC), a qualified forensic team, in-house or contracted (SIM-03.02AC), and monitoring of whether incident management runs in line with the policy (SIM-03.03AC). With SIM-04.01AC, customers can actively approve solutions, or the solution counts as approved after a certain period.

Relationship to ISO/IEC 27001:2022 Annex A

The following mapping is our own, unofficial classification by topic. 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). According to the catalogue, even an official table only shows thematic proximity, not fulfilment of the criteria (section 3.3). The short labels are ours, not titles from the standard.