C5 attestation as a SaaS provider: what a small team can make audit-ready

This page is for providers of software as a service (SaaS) who are planning a C5 attestation, including those with only a few employees. How to define the subject matter of the audit in general and what a hyperscaler platform’s attestation covers is explained on the C5 scope page. For AI services there is the C5 for AI SaaS page, for vendors of practice software the practice software vendors page. There are also separate pages for hospital software, billing service providers, DiGA and DiPA, medical devices with cloud components, providers for public administration and data centre and hosting operators.

What a SaaS provider is responsible for under C5

Everything it builds, runs and decides itself. For cloud services the catalogue assumes shared responsibilities between provider, subservice organisations and customers, and gives as examples a SaaS service operated on an IaaS platform and identity and access management for the customer’s personnel (section 3.4.4). Under section 3.4.6, software provided on another cloud service provider’s infrastructure or platform generally means a subservice organisation relationship.

A SaaS provider can exclude criteria that only apply to IaaS, with a justification; the justification has to rest on the nature and design of the service or on its principles, procedures and measures, never on missing controls (section 3.4.3). Most criteria remain applicable, because they concern organisation, personnel, development and operations.

The example: contract management with nine employees

Fictitious example, not a client. A provider runs software for managing contracts and deadlines for mid-sized companies. A large corporate asks for a C5 type 2 report in a tender. The starting position:

• Team: nine employees, five of them in development, two in operations and support, two in management and sales; plus two freelance developers.
• Platform: managed container service, managed database and object storage from a hyperscaler in a region in Germany.
• Tools delivered as SaaS: code hosting with a build and deployment pipeline (CI/CD), error tracking, an identity provider for employee sign-in, a ticketing system for support.
• Documentation: few written policies, but infrastructure as code and a complete history of all changes in the code hosting.

Decision 1: which tools are subservice organisations?

Under section 3.4.6, a service organisation is only a subservice organisation if two characteristics apply in combination: its service is relevant to customers (characteristic 1), and controls at the service organisation are needed in combination with your own to meet criteria (characteristic 2); how to check this for each entry is shown on the subservice inventory page. For SaaS providers the question mainly arises for their own tools. Regardless of the outcome, all service organisations that contribute to delivering the service belong in the directory under SSO-04.

Agree the classification with your auditor. It pays to ask whether a data flow is needed at all: if you prevent customer data from reaching a tool, you save yourself the subservice organisation disclosures, but you need evidence that the block works.

Decision 2: segregation of duties when a few people do everything

OIS-04 requires conflicting tasks to be segregated based on a risk assessment, for example development, testing and release of changes, or administration of the rights framework. Important for small providers is OIS-04.03B: if segregation of duties cannot be implemented for organisational or technical reasons, the provider establishes compensating controls that detect unauthorised or unintended changes and enable a timely response. Add to that an inventory of the conflicts and the measures that resolve them (OIS-04.04B). DEV-10.01B helps: “Authorised personnel or system components of the cloud service provider approve changes”, so an automatic approval based on defined criteria is possible.

This is what a compensating control can look like in the example (our own sample control description):

Decision 3: internal audits without an internal audit function

COM-03 requires internal audits at least annually by subject matter experts who are not in the line of authority of the area under review (COM-03.02B). If the provider’s size does not allow this, it puts alternative measures in place so that the audits remain impartial. The supplementary information to COM-03.01B also names commissioned expert third parties as subject matter experts, so an external auditor is an obvious route. In the example, an external auditor carries out the annual internal audit. We recommend that this should not be the same auditor who later issues the C5 attestation, because they would otherwise be auditing their own preparatory work; whether that would be compatible with their independence is for the auditor to judge (see choosing an auditor).

Decision 4: freelance developers

In the example, the two freelance developers work within the provider’s processes: in the same code hosting, with the same approval rules. According to the supplementary information to DEV-02, this is not outsourced development; the catalogue expressly excludes the “integration of external personnel into the processes of the cloud service provider”. The provider’s own controls apply to them, for example on personnel and access, plus the control from decision 2.

DEV-02 only applies when a service organisation develops components of the service according to its own processes, for example an agency that builds and delivers a module in its own environment. Then the following must be agreed by contract: secure development at the level of your own, acceptance testing and evidence that known vulnerabilities have been ruled out (DEV-02.01B). Before that comes a risk assessment covering, among other things, source code management, access to development and test environments, and subcontractors (DEV-02.02B). If you include the additional criterion DEV-02.02AC in this case, changes from outsourced development are additionally tested by your own personnel. See also Development (DEV) domain.

Attestation engagement or direct engagement?

The catalogue describes the direct engagement as particularly suitable for providers whose system of internal control is not yet sufficiently documented; the auditor then takes stock of the system and no system description from the provider is needed (section 3.4.4.2). For a small team that sounds convenient. In our assessment it saves less than it seems: you need policies under SP-01, a risk assessment and evidence in both cases, and the auditor needs time from your experts to take stock. In the example, the provider chooses an attestation engagement because the corporate running the tender wants to read a system description. How both types of engagement work is shown on the C5 audit page.

Evidence from the tools instead of from documents

A small team saves time if evidence is produced where the work is done anyway. The following list applies to the example; each item of evidence is recorded with source, owner and time reference in an evidence register.

Possible gaps at small SaaS providers

• Tools missing from the directory of service organisations. Cause: development booked them by credit card. Effect: data flows and subservice organisations are missing from the system description. Remedy: go through the invoices of the last twelve months and classify every tool.
• Segregation of duties only on paper. Cause: everyone has administrator rights “just in case”. Effect: the compensating control does not work, because deployments outside the pipeline cannot be detected. Remedy: set up an emergency access account, remove standing rights, log every use.
• Policies without approval and version. Cause: rules live in a wiki without version status. Effect: SP-01 requires version control and approval by top management or an authorised body. Remedy: version policies in the code hosting and document approvals there.