C5 domain PSS: what your service has to offer customers in terms of security

This page covers the PSS domain (Product Safety and Security) of C5:2026, section 5.17 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the PSS domain about?

PSS looks at what the service delivers to its customers. The catalogue states the objective as providing customers with up-to-date information on secure configuration and known vulnerabilities, as well as appropriate mechanisms for troubleshooting and logging and for the authentication and authorisation of the customers’ users (section 5.17). How the provider’s own personnel log in and which rights they have is governed by the IAM domain.

The domain comprises twelve criteria, PSS-01 to PSS-12, with 39 basic subcriteria, 2 sharpening and 11 complementing additional subcriteria. All twelve already existed with the same number in C5:2020, but several have been tightened considerably. According to the BSI change history, PSS-05 now requires multi-factor authentication instead of “strong” authentication, PSS-03 requires suppliers’ vulnerability information to be consulted at least daily, and PSS-12 requires the provider’s service organisations to adhere to the selected region as well.

Starting point: a SaaS provider with a web application, an API and an app

Fictitious example, not a client. A provider runs management software for insurance brokers as SaaS: client files, contracts, claims and commissions. It includes a web application, an application programming interface (API) for comparison calculators and a mobile app that the brokers install on their own devices. The service runs in a German region of a large cloud service provider.

Before the project, the situation looks like this:

• There is a help page with user manuals. It contains no security guidance, for example on assigning roles or on the customers’ obligations.
• A tool in the pipeline finds vulnerabilities in libraries. Customers learn nothing about them, not even when a vulnerability in the app is not fixed.
• Users can switch on multi-factor authentication themselves. A brokerage cannot make it mandatory for its staff.
• Password reset links are valid for seven days.
• According to the platform setting, the backups are stored in a second region in another European country; the contract only mentions “data centres in Germany”.

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

PSS describes what the provider delivers to its customers; eleven of the twelve criteria therefore have a customer side. The platform in the example is a subservice organisation. Our classification for the example:

All PSS criteria except PSS-02 contain complementary customer criteria. PSS-01.03B additionally requires the user documentation to describe all necessary complementary user entity controls (CUECs). The same list belongs in the system description as complementary customer controls (CUEC); how to agree them with customers is shown on the page Complementary customer criteria. The auditor does not test these controls at the customer, only whether they are fairly presented.

Which PSS criteria apply to a SaaS service?

Not every PSS criterion fits every service model. The catalogue says so itself in the supplementary information:

• PSS-10 Software Defined Networking and PSS-11 Images for Virtual Machines and Containers: each criterion “is typically not applicable to the SaaS service model”; they concern services with which customers run their own networks, machines or containers. How the provider separates customers from one another is shown on the page Tenant separation, how it operates its own container platform in an auditable way on the page Containers and Kubernetes.
• PSS-04 Error handling and Logging Mechanisms only applies to system components under the responsibility of the customer. For SaaS services their number may be so limited that the criterion is not applicable.
• PSS-12 Region of Data Processing and Storage does not require offering multiple regions or partitions; a provider that offers only one partition does not deviate from the criterion.

You exclude a criterion that is not applicable with a justification; according to minimum content item 4, the justification belongs in the system description. According to section 3.4.3 it may only be based on the nature and design of the service or on the provider’s principles, procedures and measures, never on controls being missing or ineffective. For the example, the description states: customers do not operate their own networks, machines or containers, so PSS-10 and PSS-11 are not applicable. PSS-04 deserves a closer look, because with the mobile app and the roles of the customer administrators the example has areas that the customer controls itself.

According to the catalogue, PSS-12 supplements the general condition GC-01, in which you state countries, regions and locations, see General conditions; for customers with sovereignty requirements it is, according to the catalogue, a prerequisite for technical service sovereignty, see C3A.

Example control description for PSS-03

PSS-03 requires a coordinated process through which customers receive regularly updated information about known vulnerabilities associated with the service: known exploited vulnerabilities, those with a patch or mitigating measure (N-Day) and those for which the provider is unlikely to provide a patch (Forever-Day), with a justification (PSS-03.01B). This also applies to assets that customers have to install themselves, in the example the app. The vulnerabilities are presented with CVE references and with assessments based on CVSS and on EPSS, SSVC or a similar metric (PSS-03.04B), and the provider consults the vulnerability information of its suppliers and service organisations at least daily (PSS-03.05B). Our example control for the provider above (own wording, not catalogue text):

According to the supplementary information on PSS-03.03B, the component list does not have to be handed over to customers; it serves to identify vulnerabilities. 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

Much of the PSS evidence consists of properties of the product: configurations, functions, published documents. The auditor wants to see them for the version that was in productive use in the period. 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. Product changes such as enforceable multi-factor authentication need a release before the audit period begins.

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

Additional subcriteria with an effect on sales include PSS-01.01AC (timely notification about planned modifications to the service), PSS-03.02AC (disclosure of vulnerabilities in accordance with the Common Security Advisory Framework version 2.0 or higher and the BSI Technical Guideline TR-03191), PSS-12.01AS (cloud service derived data only in the region as well) and PSS-12.01AC and PSS-12.02AC (selectable partitions in which identity management, privileged access, logging and keys also remain).

Relationship to ISO/IEC 27001:2022 Annex A

ISO/IEC 27001 governs the ISMS of your own organisation; PSS, by contrast, requires functions and information that the service offers to its customers. The following mapping therefore only shows thematic proximity and is our own, unofficial classification. 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.