Audit readiness for TSPs: evidence packs, sampling, and common findings.
If you can produce evidence for REQ-7.8/7.9/7.10 on demand, you can survive most audits and procurement security reviews.
Structured answer sets in this page tree.
Cited legal and guidance references.
Most ETSI EN 319 401 audits fail on operational proof, not on policy intent. Auditors, conformity-assessment bodies, and relying parties ask the same core questions: do you continuously monitor, can you detect and classify incidents, can you report within 24 hours when required, do you scan and test on a defensible cadence, can you prove supplier oversight, and can you retain evidence with reliable UTC time. This page focuses on what gets sampled, what good evidence looks like, and how to avoid repeat findings.
Audits focus on whether your control system works in practice and whether evidence is traceable to your scope. The most sampled areas are the operational clauses: network security, vulnerability management, monitoring/logging, incident response/reporting, and evidence retention.
Policies matter only as far as they explain and govern the operating reality. A policy with no operational proof is a finding waiting to happen.
Build a single evidence index that maps REQ categories to their proof. The index should be versioned and should link to the newest evidence, with historical evidence retained for trend and legal/procurement needs.
Treat the evidence system as an internal product: it needs ownership, change control, and reliability.
SSOT can take ETSI EN 319 401 Audit + Conformity Assessment from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.
Start from ETSI EN 319 401 Audit + Conformity Assessment and keep documents, evidence, and control records in one governed system.
Review your current process, evidence gaps, and next steps for ETSI EN 319 401 Audit + Conformity Assessment.
ETSI EN 319 401 requires regular vulnerability scans on identified public and private IP addresses, with recorded evidence that scans were performed by a competent and independent party. It also recommends quarterly scanning and requires penetration testing after upgrades/modifications that you determine are significant.
Auditors will ask two questions: (1) did you scan/test on a credible cadence and scope, and (2) did you remediate or formally accept risk with documented rationale.
ETSI EN 319 401 expects continuous monitoring/logging, detection/alarms for abnormal activity, and automated processing of audit logs with alerting for critical security events. This means manual log review without tooling is rarely defensible.
Incident response expectations include containment/eradication/recovery, communication plans, training/competence, documentation throughout detection/response, and explicit time-bound handling such as 48-hour critical vulnerability handling and 24-hour breach notification procedures for significant impact breaches.
Evidence retention is both a security and legal/continuity requirement. ETSI EN 319 401 requires recording and keeping relevant information accessible for an appropriate period (including after TSP activities cease), while preserving confidentiality and integrity.
A frequently missed detail: audit log event time must be synchronized with UTC at least once a day. If time integrity is weak, incident timelines and legal evidence become disputable.
Use this checklist as an internal readiness gate before a conformity assessment, customer audit, or supervisory review. Every item should map to evidence links in your evidence index.
Modern TSP environments rely on cloud infrastructure, managed services, external trust service components, and other outsourced support. EN 319 401 makes clear that the TSP retains overall responsibility for conformance when those arrangements exist.
Auditors increasingly sample whether supplier controls are active in practice. They look for more than contracts. They want review records, service-level enforcement, and evidence that supplier cybersecurity practices are revisited after incidents and major changes.