C5 domain PI: interfaces, data export and deletion ready for audit

This page covers the PI (Portability and Interoperability) domain of C5:2026, section 5.10 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the PI domain about?

PI answers three questions that customers ask before a procurement: How do I connect the service to my systems? Do I get my data back if I leave? And what happens to it at the provider afterwards? The catalogue sums this up in its objective: enabling access to the service via other cloud services or IT systems of the customers, obtaining the stored customer data at the end of the contractual relationship and deleting it securely from the provider (section 5.10).

The domain comprises three criteria, PI-01 to PI-03, with 6 basic subcriteria and 5 complementing additional subcriteria; there are no sharpening ones. All three criteria already existed with the same number in C5:2020. According to the BSI change history, the obligation to document interfaces has moved to the PSS domain (PSS-01); PI-01 now deals with the implementation of the interfaces. PI-03 now allows exceptions to deletion if a court order requires them or known future financial and legal obligations still require the data.

The catalogue does not require new technology just for portability: according to the supplementary information on PI-01, the provider is required neither to develop new technologies nor to share information protected as intellectual property or as a trade secret.

Starting point: a SaaS provider whose customers want to switch

Fictitious example, not a client. A provider runs software for time recording and project billing for engineering and architecture firms. The service runs on the infrastructure of a large cloud provider, with a managed database, object storage for receipts and plans and a search index. The firms connect their accounting via a REST interface. For a contract renewal, a large customer asks for a C5 report and asks in the questionnaire how it gets its data back at the end of the contract.

Before the project, the situation looks like this:

• The REST interface is documented, and the accounting entries can be exported as CSV. There is no export for receipts, plans and the change log; customers have to ask support.
• The contract terms say: “After the end of the contract, the data will be deleted.” A time frame for handing over the data, a deletion date and the customers’ cooperation are missing.
• A tenant is deleted with a script that a developer starts when needed. Backups expire on their own after their retention period; nobody knows exactly whether the search index is deleted too.
• The customer does not receive proof of deletion.

None of these points stands out in day-to-day operations. They only show up when a customer terminates, and that is exactly the case the auditor wants to see evidenced.

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

With SaaS, PI is largely the provider’s responsibility: the customer depends on the export functions the service offers. For IaaS- and PaaS-like services it is the other way round according to the supplementary information on PI-02: there the customer is generally responsible for extracting and backing up its data itself. In the example the platform is a subservice organisation. Our classification for the example:

All three PI criteria contain complementary customer criteria. Whichever customer controls you assume for your service, for example that the customer retrieves its data within the time frame, belong in the system description as complementary customer controls (CUEC). The auditor does not test them at the customer, only whether they are presented appropriately.

What has to be in the contract on handing over data?

PI-02.01B requires the contractual agreements to govern the provision of customer data after the end of the contract, insofar as the aspects are applicable to the service. If an applicable aspect is missing from the contract, the criterion is not met according to the supplementary information, and the auditor notes a deviation. Read the exact wording of the seven aspects in the catalogue. For the example we have derived guiding questions and our own example rules from them:

The time frames are example values, not catalogue requirements; the catalogue does not set a specific duration. As possible legal requirements it names the EU Data Act and, for Germany, retention obligations under Section 147 of the German Tax Code (AO) and Section 257 of the German Commercial Code (HGB). Which of these apply to your service and your contracts has to be assessed legally in the individual case. Providers that include the complementing subcriterion PI-02.01AC review these requirements at least once a year and adjust the contracts; with PI-02.02AC the provider additionally hands over cloud service derived data, such as usage logs.

Example control description for PI-03

PI-03 requires three things: the deletion of customer data, cloud service derived data and account data at the end of the contract complies with the contractual agreements (PI-03.01B), it prevents recovery by forensic means in line with the established rules of technology (PI-03.02B), and it is documented so that the customer obtains proof (PI-03.03B). The catalogue names multiple overwriting or deletion of the encryption key as examples of suitable methods. Our example control for the provider above (own wording, not catalogue text):

Deletion via the key is our recommendation for backups that cannot be processed individually; it requires every tenant to have its own key. How to manage keys is covered by the CRY domain. Whether the control covers all subcriteria is for the auditor to assess.

What evidence the auditor wants to see

For PI, evidence comes from the contract, the interface documentation and the cases of terminated contracts. If no contract ends in the audit period, there is no real deletion case; then clarify early with the auditor how you evidence the procedure. Examples from our scenario:

An evidence register records which evidence belongs to which subcriterion; 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 gaps to close first is decided by prioritising measures across all domains. Contract changes need lead time; plan them before the start of a type 2 period.

All criteria of the PI 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 complementing subcriteria of PI-01 concern customer requirements that can come up in sales: an application firewall in front of administration interfaces accessible from public networks (PI-01.01AC), and the connection of customers’ own identity providers via a standardised protocol with clear documentation (PI-01.02AC, PI-01.03AC). Which of them you include depends on your customers.

Relationship to ISO/IEC 27001:2022 Annex A

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.