C5 domain SP: approving and reviewing policies and managing exceptions

This page covers the SP domain (Security Policies and Procedures) of C5:2026, section 5.2 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the SP domain about?

SP governs the cloud service provider’s policy framework. The catalogue states the objective as “Provide policies and procedures regarding security requirements and to support business requirements” (section 5.2). Three criteria cover this: SP-01 sets out how policies are structured, versioned, approved and communicated; SP-02 governs review and approval; SP-03 the handling of exceptions.

The domain has eleven basic subcriteria, no sharpening and three complementing additional subcriteria, all of them under SP-03. Its effect reaches far: the supplementary information on SP-01 lists 32 policies and procedures from other criteria to which these rules apply, from the Information Security Policy (OIS-02) through the Policy for the Use of Cryptographic Mechanisms (CRY-01) to the Policy for Security Incident Management (SIM-01). Why you should therefore define the uniform structure under SP-01 before all other policies is explained on the page prioritising measures. This page is about the two processes on which audits in this domain depend: approval and exceptions.

Starting point: many policies, no order

Fictitious example, not a client. A provider runs a learning platform through which hospitals and care facilities organise mandatory training for their staff, for example on hygiene, fire safety and data protection. The provider has around 35 employees, and the service runs as SaaS on the infrastructure of a large cloud provider. A hospital group requires a C5 type 2 report.

Before the project, the situation looks like this:

• Around 40 policies and instructions sit in the wiki, each structured differently. Some name no owner, some have no date.
• Approval happens by agreement in the team chat. Who agreed there and whether that person was authorised to do so can no longer be traced.
• Some documents have not been looked at for three years, although the service now uses a new database.
• A large customer uploads participant lists via SFTP with password login, although the internal cryptography policy requires keys. Sales agreed to the deviation by e-mail.
• An older network device cannot run the prescribed monitoring agent. This is known, but not recorded anywhere.

The last two points correspond exactly to the two examples the catalogue gives for exceptions: an organisational unit deviates in order to meet the requirements of a customer, and a system component lacks technical properties to configure it as prescribed.

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

SP is the provider’s responsibility. The platform has its own policy framework, which is not part of your audit. The customer is involved in exceptions: SP-03 is the only criterion of the domain with complementary customer criteria. Our classification for the example:

You set out in the contract which information on exceptions you provide to customers. The customer controls you assume belong in the system description as complementary customer controls (CUEC).

What does an auditable approval path for policies look like?

SP-01.04B requires approval by top management or an authorised body, SP-02.02B approval of revised versions by the appropriate level of management before they become effective. According to the supplementary information, top management is the appropriate level for the information security policy. For the auditor to be able to follow this, responsibility has to be defined per document type. Our approval matrix for the example:

The authorisation of the information security officer is itself evidence: it shows that the information security officer is an “authorised body” within the meaning of SP-01.04B. The approval path itself is the same for every document:

1. Draft in the uniform template with objectives, scope, roles with substitution, roles of other organisations, measures and legal requirements (SP-01.01B).
2. Expert review by subject matter experts, with a view to organisational and technical changes and to new legal or regulatory requirements (SP-02.01B).
3. Approval according to the matrix, in the document management system with name, date and version, before the version takes effect (SP-01.04B, SP-02.02B).
4. Communication to all relevant internal and external personnel, appropriate to the need, for example with read confirmation or a short training session on significant changes (SP-01.02B, SP-02.02B).
5. Resubmission no later than twelve months after approval and additionally on every significant change to the service (SP-02.01B).

As significant changes, the supplementary information on SP-02 names, among others, major changes to architecture or platform, substantial legal changes such as NIS2, DORA or GDPR, reorganisations, major security incidents and changes in top management. For the move to the new database in the example this means: the affected policies should have been reviewed at the time of the move, not only at the next annual date.

How do you keep an exception register under SP-03?

SP-03.01B requires a list of all exceptions with the associated controls. Every exception goes through the risk process under OIS-07 with approval and risk acceptance by the risk owners (SP-03.02B), the aggregated risk from several exceptions is taken into account (SP-03.03B), every approval has a defined validity and is reviewed at least annually (SP-03.04B). Our template, with the two cases from the example:

SP-03.05B sets the hard limit: exceptions that would result in a deviation from an applicable C5 criterion within the scope of the audit are not permitted. An example: a team wants to postpone the annual review of access rights by six months. IAM-05.01B requires it at least once a year; there must be no exception to this, the review has to take place. The exception register therefore cannot be used to legitimise a gap with respect to the catalogue.

Example control description for SP-03

Our example control for the provider above (own wording, not catalogue text):

The monthly check for expiry goes beyond the basic criteria and corresponds to the complementing subcriterion SP-03.02AC. We recommend it even if you do not include that subcriterion, because otherwise expired exceptions continue unnoticed.

What evidence the auditor wants to see

For SP, what counts are documents with version, approval and date, and the records showing that they were communicated and reviewed. Examples from our scenario:

An evidence register assigns each subcriterion its evidence; how to keep one is shown on the page evidence and documentation. You will find a template for it under C5 templates.

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 SP 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 three complementing subcriteria belong to SP-03: approval by the appropriate level of management (SP-03.01AC), monitoring of the list to prevent approved exceptions from expiring (SP-03.02AC) and timely remediation of deviations (SP-03.03AC).

Relationship to ISO/IEC 27001:2022

An ISMS certified to ISO/IEC 27001 brings a lot to SP. According to the supplementary information on SP-02.01B and SP-03.01B, controls on these criteria are most likely also tested in the ISO certification audit; in a separate audit, the C5 auditor can inspect the ISO report instead of testing again, if the evidence provided is conclusive enough. What else can be reused from ISO 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.