Prioritising C5 measures: what comes first and who owns it

This page sets the order for measures that hold up several C5 domains at once. How to close gaps within one domain belongs to that domain in the criteria catalogue. Here the question is the sequence across domains. The list of measures comes out of the C5 readiness assessment, and the remediation plan under the C5 Equivalence Ordinance (C5GleichwV) is a separate document with statutory deadlines (see C5 Equivalence Ordinance).

What makes a measure a blocker?

A measure is a blocker if other measures cannot sensibly start or cannot be audited without it. We use five characteristics. If one of them applies, the measure moves up:

1. Other criteria build on it. Many criteria in the catalogue refer to another one, for example policies “documented, communicated and provided in accordance with SP-01” or “a risk assessment in accordance with OIS-07”.
2. It has to be running before the audit period. A type 2 report assesses operating effectiveness throughout a period that should cover at least three months. Anything that only starts halfway through is missing for the first weeks.
3. It follows an annual cycle. Tests, reviews and internal audits with an annual frequency have to take place within the period and be evidenced.
4. It depends on third parties. Subservice organisations, customers or contract partners have their own lead times.
5. It changes the scope or the system description. Anything that shifts the subject matter of the audit makes later work obsolete.

Where the catalogue itself sets dependencies

Two criteria appear particularly often in the text of other criteria. By our count of the German version 1.1.0, more than 30 criteria from at least 13 domains each name OIS-07 or SP-01 explicitly. If you tackle these two late, you will have to revisit the dependent controls later.

Risk-based criteria have a special case: if the risk assessment concludes that there are no risks to mitigate, the provider states this justification when presenting the applicability of the criterion (section 3.4.3). That too requires a documented risk assessment.

Prioritisation aid: blockers, sequence, owners

The table is our working aid, not a requirement of the catalogue. It ranks eleven measures that can affect several domains in many C5 projects. The column “Typical owner” names typical roles. In small organisations several of them sit with one person.

In which order do you work through the stages?

The stages overlap, but a stage should only start once the previous one exists in draft. Our recommendation:

• Stage 1, foundation: keep it small and decide quickly. A scope decision that stays open for three months delays everything else by three months.
• Stage 2, framework: policies, roles, cryptography and logging in parallel, but with the same structure under SP-01. Plan the approval as one bundle, with management or the body it has authorised for this.
• Stage 3, operation: from here on the calendar counts. For a type 2 report, the controls should be operating when the period starts. For an initial engagement, the catalogue allows two ways of providing evidence (section 3.4.11). If controls are not yet fully executed, for example completion of the business impact analysis in all organisational units or disaster recovery tests, the provider may provide evidence for the implementation of such controls, for example by records about the planning or templates for the documentation. If controls are not yet implemented in the production environment, the provider can evidence them in a non-production environment that is configured like a production environment. That is no plan for regular operation.
• Stage 4, report: the system description grows from stage 1 onwards. If you only write it at the end, you will find contradictions there between the document and actual operations.

How much time has to lie between stage 1 and the customer’s deadline is worked out in the backward planning. The C5 check gives a rough picture of which areas you are still missing. Its fields of action are a starting point for the stages, not an assessment per criterion.

Who is responsible for what?

Each measure needs exactly one responsible person with a deputy. This is also in line with the catalogue: under SP-01.01B, policies describe roles and responsibilities, including substitution rules. We recommend this split:

• Management: scope, budget, approval of the policies, acceptance of residual risks, management statement.
• Information security officer or C5 project lead: plan of measures, risk methodology, policy framework, system description, coordination with the auditor.
• Specialist teams (operations, development, HR, procurement): implementation and evidence in their area.
• Sales and product management: customer controls, contract changes, customer deadlines.

If much of the work sits with a few people in a small team, watch the segregation of duties: OIS-04 requires conflicting tasks to be segregated and allows compensating controls where this is not possible for organisational reasons. What this looks like for SaaS providers with few employees is shown on C5 for SaaS providers.

How to order measures within a stage

Within a stage, a simple rating with four questions helps, each scoring zero to two points. The total gives the order. In a tie, the longer lead time decides. The scale is our own.

Example: document exchange for tax advisory firms

Fictitious example, not a client. A provider runs a platform on which tax advisory firms and their clients exchange receipts and tax assessments, as SaaS on a public cloud platform in Germany. It holds an ISO 27001 certificate. The gap analysis results in 34 open measures. A first type 2 period is planned from 1 September 2027, so under C5:2026.

The team wanted to start with a penetration test and a new SIEM because both are visible. Applying the five characteristics, the plan looks different:

• First the asset inventory: a second cloud account runs test systems with copies of real client data that nobody had in scope so far. This changes the scope, the risk assessment and the hardening.
• Then the mailing service for notifications: it receives document names and client names and is classified as a subservice organisation. The contract needs an addendum, and the service provider has a lead time of two months.
• Then policies under SP-01, based on the existing ISO documents, with bundled approval by management.
• The penetration test moves into the audit period because OPS-22.01B requires it at least once a year. That way it serves as evidence for the period. The SIEM follows after the logging concept.

Result: the visible measures come later, and stages 1 and 2 are complete in draft three months before the period starts.

Typical mistakes when prioritising

• Working through the catalogue in order. Cause: the catalogue is organised by domain and does not reflect dependencies. Effect: domains at the end of the list, such as SSO or BCM, start too late even though they involve lead times with third parties. Remedy: sort by the five characteristics.
• Tools before requirements. Cause: a new tool shows progress quickly. Effect: it is later adapted to the policies and the risk assessment or reconfigured. Remedy: introduce tools only after stage 2, unless they provide evidence that is needed before the period.
• Placing annual controls before the period. Cause: you want to have the test “done”. Effect: the date lies outside the audit period and is no evidence for it. Remedy: deliberately place annual controls within the period, early enough to repeat them if there are deviations.