Evidence for a C5 attestation: building and maintaining an evidence register

A C5 audit depends on evidence. This page shows how to organise that evidence in an evidence register, which fields the register needs and what matters for timing and sampling. What belongs in the system description itself is covered on C5 system description. The course of the audit is explained on C5 audit process.

What documentation does a C5 audit need?

Three kinds of documents that have to fit together. In an attestation engagement, the system description describes the service and the controls. Governing documents such as policies and work instructions set out how the controls are meant to operate. Evidence of performance shows that they actually operate: exports, tickets, logs, approvals, test reports.

The catalogue does not require an evidence register. It does describe how the auditor reaches a conclusion: through inquiries combined with observation and inspection of records, the auditor determines whether the described system has been implemented (section 3.4.7). In the report, the auditor states the nature and extent of the tests performed, such as inquiry, observation, inspection or reperformance, and gives abstract descriptions of the documents and files relied on (section 3.4.13, item 4). A register makes sure you can produce these records on request instead of searching for them during the audit.

It also helps management: for its management statement it needs a reasonable basis of its own, in a type 2 audit for example its own monitoring of the controls over the period (section 3.4.5.2). A well-kept register shows where evidence is missing before the auditor finds out.

Which fields does an evidence register need?

We recommend the following fields as a minimum. This is our recommendation, not a catalogue requirement. Our template contains all of these fields, plus “Created on” and one column each for whether the evidence is relevant for type 1 or type 2.

The blank template as CSV and Excel file is on the Templates page.

Example: extract from an evidence register

Fictitious example, not a client. A provider runs a document management system as SaaS for municipal administrations. A type 2 report is planned for the period 1 July 2027 to 31 December 2027 under C5:2026. Extract from the register, criteria titles as in the English catalogue version 1.0.1:

Two things stand out in this extract. E-012 depends on E-011: only if you know all production deployments can you show that every change without a regular approval note has an emergency ticket. And E-052 lies in the future. A date in the register makes sure the exercise really takes place within the period and not after it.

Timing: what type 1 and type 2 require in evidence

In a type 1 audit the auditor assesses the design of the controls as of a specified date, in a type 2 audit also their operating effectiveness over a period (section 3.4.4). For the register this means:

• Type 1: evidence that each control was designed and implemented as of the specified date (section 3.4.9, item 8), such as the current policy, the configuration, a first performance. When type 1 is the right choice is explained on type 1 or type 2.
• Type 2: evidence for the whole period, which should cover three to twelve months. For recurring controls this means evidence for every performance in the period, not just the last one. A quarterly control has two performances in a six-month period.
• Initial audit: if controls are not yet fully executed, such as a restore test, the catalogue allows evidence in the form of planning records or documentation templates; controls not yet running in production can be evidenced in a non-production environment configured like production (section 3.4.11).

Our recommendation: have evidence created when the control is performed, with a date from the system, not afterwards. A log written in December for a control in August does not show that the control ran in August.

Sampling in the type 2 period: what it means for your evidence

In a type 2 audit the auditor tests operating effectiveness under ISAE 3402 (section 3.4.10). In the report the auditor has to state whether the items tested are all items or a selection (sample) of the items in the population, and describe at least the general approach to the extent of testing, for example depending on the number of items or the frequency of the control. Where deviations are found, the auditor states the sample size used and the number and nature of the deviations (section 3.4.13, item 4).

The catalogue does not set sample sizes. The BSI FAQ says that operating effectiveness is determined using a statistical sample with a 95% confidence interval (our translation). The C5:2026 catalogue does not say this. The auditor decides how large the selection is. What matters for you is something else:

1. The population has to be complete. The auditor draws the selection from a list of all performances, such as all deployments or all leavers in the period. If cases are missing from it, the selection is worthless. Record in the register which system the list comes from and how you show it is complete.
2. Every item has to be evidenced individually. If the auditor picks the leaver of 14 September, you need the notification and lock log for exactly that case. Summary evidence (“all leavers in the quarter processed”) is not enough for this.
3. The information has to be reliable. The auditor considers whether the information used in the operation of a control is reliable (section 3.4.9, item 6). Exports with source system, query and timestamp are better than edited spreadsheets.
4. Deviations count too. A criterion is not met if one of its subcriteria is not met, and deviations are reported even if the auditor concludes the criterion was achieved overall (sections 3.4.12 and 3.4.13). If you find a missing item yourself, document it with cause and action. The report includes when and how the provider detected it.

Who maintains the register and how often?

One person keeps the register, the specialist teams provide the evidence. Our recommendation: the lead person from information security management checks monthly whether the evidence due has come in and reports gaps to the owners and to management. This creates, along the way, the monitoring on which management can base its statement in a type 2 audit (section 3.4.5.2).

Do not put the evidence itself into the register. It points to the source system or a protected store. Evidence often contains personal data, such as names in leaver lists, or configuration details. Give the auditor only what is needed for the selection, and restrict access to the store.

Typical gaps in an evidence register

Which controls need evidence in which order depends on your starting point. A C5 readiness assessment shows where evidence is missing and which gaps would block an audit.