C5 domain OIS: setting up roles, committees and the risk process for the audit

This page covers the OIS domain (Organisation of Information Security) of C5:2026, section 5.1 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the OIS domain about?

OIS governs how the cloud service provider organises and manages information security. The catalogue states the objective as “Plan, implement, maintain and continuously improve the information security framework within the organisation” (section 5.1). In practice this means: there is an ISMS with a scope that covers the service, an information security policy adopted by top management, clear boundaries towards customers and service providers, segregated duties and a risk process with named risk owners.

The domain comprises ten criteria, OIS-01 to OIS-10, with 34 basic subcriteria, 2 sharpening and 5 complementing additional subcriteria. According to the change history, OIS-05 (threat intelligence), OIS-09 (risk treatment) and OIS-10 (information security in project management) are new compared with C5:2020. The numbers have shifted: the risk management policy, OIS-06 in C5:2020, is now OIS-07. Many other criteria refer to OIS-07, for example “Based on a risk assessment (cf. OIS-07)” in AM-10 to AM-12. A weak risk process therefore has effects far beyond this domain.

Starting point: a SaaS provider with an ISO certificate

Fictitious example, not a client. A provider runs a platform on which medium-sized companies and local authorities receive incoming electronic invoices, check them and pass them on to their accounting. The provider has around 70 employees, and the service runs as SaaS on the infrastructure of a large cloud provider. The provider is certified to ISO/IEC 27001, the scope covers development and operations. Some customers are local government administrations.

Before the project, the situation looks like this:

• The risk register is a spreadsheet that the information security officer revises once a year before the surveillance audit. The move to a new database architecture in spring did not trigger a reassessment.
• The information security officer signs off residual risks herself, because otherwise nobody feels responsible.
• What customers have to do themselves is scattered across terms and conditions, service description and an onboarding wiki. There is no coherent document on it.
• The operations team reads security warnings from vendors and authorities when they happen to notice them; there is no link to the risk register.
• The project “AI-assisted document recognition” has been running for three months without anyone having assessed its risks.
• A “security meeting” takes place once a month; minutes exist only occasionally.

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

OIS lies with the provider. Even if it outsources activities to subservice organisations, the responsibility for the risks remains with the provider according to the supplementary information on OIS-08 and OIS-09. Our classification for the example:

Whichever customer controls you assume belong in the system description as complementary customer controls (CUEC); how to agree these obligations with customers is shown on the page complementary customer criteria. The auditor does not test such controls at the customer, only whether they are presented appropriately.

What does an auditable role and committee model look like?

The catalogue does not prescribe a particular committee. It does, however, require actions by particular roles: top management adopts the policy (OIS-02.01B), risk owners accept residual risks (OIS-07.01B, OIS-09.03B), the level of management responsible for the security of the cloud service evaluates risk assessment and treatment plans (OIS-07.01B no. 6). According to the supplementary information on OIS-04, roles that review risks should be different from roles that own risks. An information security steering committee appears in the catalogue only in a list of examples (supplementary information on SP-02). We recommend one anyway, because that is where the decisions with date and participants are made that the auditor wants to see. Our model for the example:

The column “Not combined with” is the core of an inventory of conflicts under OIS-04.04B. How small teams solve segregation of duties with compensating controls is shown on the page C5 for SaaS providers. Exceptions to policies go through the same risk process; the procedure for this is on the page security policies and procedures.

How does the risk process under OIS-07 to OIS-09 work?

OIS-07 requires a documented methodology that delivers comparable and reproducible results; OIS-08 governs the assessment, OIS-09 the treatment. The catalogue allows qualitative, semi-quantitative and quantitative methods and does not require specific formal frameworks; lean forms of documentation are expressly possible where appropriate. This is how we set up the process for the example:

As triggers, the supplementary information on OIS-08.01B names, among others, changes to the threat landscape, security incidents, new legal or contractual requirements, changes to the organisation or the architecture, events at service organisations, exceptions to policies and critical vulnerabilities. Record in your methodology which of these triggers lead to an assessment in your organisation and who reports them.

Example control description for OIS-08

OIS-08.01B requires the risk management process to be performed “as needed and at least annually”, OIS-08.06B a review by the risk owners at least annually and in case of significant changes to the service. This is exactly where a register that is only maintained before the audit fails. Our example control for the provider above (own wording, not catalogue text):

The 20 working days are our recommendation; the catalogue sets no deadline for the assessment as needed. What matters is that your methodology sets a deadline and that you meet it. For a type 2 report the auditor tests whether the control was effective over the whole period, including whether every trigger in the period had an assessment.

What evidence the auditor wants to see

For OIS, evidence consists mostly of documents and minutes with date, version and approval. Examples from our scenario:

An evidence register assigns each subcriterion its evidence and due date; how to keep 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).

Which of these gaps block the audit and in which order to close them is settled in prioritising measures; risk methodology and first assessment are part of the foundation there.

All criteria of the OIS 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 additional criteria concern the certificate (OIS-01.01AS, OIS-01.01AC), monitoring of segregation of duties (OIS-04.01AC, OIS-04.02AC) and risk management: OIS-08.01AS additionally requires monitoring the evolution of the risks, OIS-08.01AC integration into an enterprise risk management programme, OIS-08.02AC consideration of internal threat actors.

Relationship to ISO/IEC 27001:2022

OIS-01.01B requires an ISO/IEC 27001-compliant ISMS; according to the supplementary information, a certificate is not needed for the basic subcriterion, the auditor evaluates the documentation in a focused way. The sharpening OIS-01.01AS requires a valid certification whose scope covers the service. What you can reuse from a certified ISMS and what is still missing is set out on the page C5 and ISO 27001.

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.