Audit and certification test evidence

What audit and certification test evidence includes

A PCI DSS assessor who selects requirement 11.4.4 asks for the penetration test finding, the correction, and the repeated test. A SOC 2 service auditor who samples a change asks for the ticket, the approval, the test record, and the person who deployed the change. Each request resolves to linked records in one evidence pack. The testing requirements per standard are on the PCI DSS, SOC 2, DORA, PSD2 SCA, and RPAA pages; this page covers how the evidence is built. Clause references were checked on 2026-09-16.

Traceability from requirement to result

The matrix starts from the requirement at its deepest reference: PCI DSS v4.0.1 11.4.4, Commission Delegated Regulation (EU) 2018/389 Article 4(3)(b), DORA Article 24(6), or an Annex A control of ISO/IEC 27001:2022 from your Statement of Applicability. Each reference maps to product requirements, each product requirement to test case IDs, and each test case to its latest run and evidence file. An engineering lead reads the chain backwards: from a failed run to the requirements that lose support.

What each test record carries

• Requirement and test identity. The requirement reference, the test case ID, and the test case version. A test edited later keeps its old version on earlier records.
• Build and environment. Commit SHA, build number, deployed service versions, environment name, and configuration version, so the auditor can match the tested build to the release in production.
• Time. Start and end timestamps in UTC from a synchronised clock. An examination of operating effectiveness throughout a period needs runs dated across that period, and a cluster of runs in the week before fieldwork shows the gap.
• Data. The ID of the synthetic data set and the test accounts the run used, so the record names the data behind each result without holding real cardholder data or account data.
• Raw output. HTTP requests and responses, logs, and query results, stored as files with a SHA-256 hash in the record.
• Result and sign-off. Pass or fail against an expected result written before the run, the defect ID on failure, the person or pipeline that ran the test, and the role and date of a reviewer who did not write or run the test.

ITGC evidence for program changes and development

Auditors who test IT general controls (ITGC) over program changes select a sample of changes from the period and inspect authorisation, testing, and approval before deployment. Test records map to program change controls through the change ticket: each ticket links to the CI run on the deployed commit and to the reviewer's sign-off. Test records map to program development controls through the traceability matrix: a new system's requirements link to acceptance test runs and the sign-off before go-live. Access and IT operations controls draw on system logs and access reviews, which this service does not produce.

Gap report before the assessment

Before fieldwork, the gap report lists each requirement in one of five states: no test case, no run inside the audit period, a failed run with no retest, a record missing build, environment, or reviewer fields, or a test that does not exercise the control. A lockout test that checks the error message after five failed attempts, and never submits correct credentials on the sixth attempt, does not show that access stays blocked. Each gap carries an owner, a fix, and a rerun date.

Retest evidence after remediation

The retest record links the failed run, the defect, the fix commit, and a passing rerun of the same test case version on a build that contains the fix, plus the regression runs around the change. A rerun on an edited test case, or on a build without the fix commit, is marked as unsupported. The record is input to the assessor's review of PCI DSS v4.0.1 11.4.4 and to remediation validation under DORA Article 24(5).

Retention and integrity

Evidence folders are write-once after sign-off, and a SHA-256 hash per file shows that no file changed afterwards. Each folder carries the retention period from your records policy, such as the period under section 40 of the Retail Payment Activities Regulations for a payment service provider subject to the Retail Payment Activities Act. A disposal log records who deleted a folder, when, and under which policy clause.

Evidence for the auditor's work

The Qualified Security Assessor completes the PCI DSS Report on Compliance, the service auditor issues the SOC 2 report, and the certification body decides ISO/IEC 27001 conformity. The SCA audit under Delegated Regulation 2018/389 Article 3 and a MiCA authorisation application under Article 62(2)(j) can draw on the same dated test records. The evidence pack is input to each of these reviews; the auditor or authority decides which records to rely on and runs its own tests.