An ICT audit shouldn't be a last-minute scramble of screenshots, exports and meeting minutes. A defensible sample demonstrates that a control exists, was executed in the relevant period, has a clear owner, and left a verifiable trail. This article provides a practical approach to selecting and documenting evidence samples so you can defend audit conclusions without turning every audit into a full replay of every log, ticket or record. The guidance is aimed at compliance managers, DPOs, CISOs, IT managers and internal auditors. It is operational guidance, not legal advice.
Why sampling matters in ICT audits
Auditors rarely need to inspect every single event or record produced by systems, people and suppliers. The objective of sampling is to reduce uncertainty about whether a control works in practice by examining a representative, explainable subset of evidence.
European regulations such as NIS2 and DORA—and commonly referenced frameworks like ISO standards and GDPR obligations—require organizations to demonstrate governance, technical and organizational measures, risk management and incident/vendor oversight. Those frameworks expect evidence that aligns with scope, risk and responsibilities; sampling is therefore part of the proof, not an administrative detail.
Start by defining population, period and control objective
The most common early mistake is grabbing files before defining the population. The population is the complete set you could sample from: all incident response tickets in a quarter, all privileged access requests in six months, every backup/restore test in a year, or all critical ICT suppliers listed in your vendor register.
Before you extract anything, write one clear sentence linking the control to its population, period, owner and expected evidence. For example: “Verify that privileged access reviews were completed for all admin accounts in Q2, evidence: review reports and approvals, owner: IT security manager.” If that sentence is fuzzy, the sample will be open to challenge.
Using a taxonomy of evidence mapped to controls, owners and requirements helps keep the selection consistent. See related guidance on evidence types in /en/blog/evidence-for-audits.
Define the sampling logic: explainable beats convenient
There is no single sampling method that fits every audit. Choose the approach that matches the control’s risk profile, execution frequency, historical quality of evidence and the potential impact of a control failure. The key requirement is to document why the chosen sample is appropriate for the verification goal.
Risk-based sampling
Use risk-based selection when controls protect critical systems, sensitive data, externally exposed assets or regulated processes. Start by including the highest-impact items, then add ordinary cases to confirm the control works routinely. For example, when sampling incident tickets, include all high-severity incidents and a random subset of medium/low severity incidents.
Random or systematic sampling
Random sampling reduces bias and is useful for large, homogeneous populations like routine change requests or standard support tickets. Systematic sampling (e.g., every Nth record after a documented start point) works when the register is complete and ordered. Preserve the extraction rule so others can reproduce the sample.
Targeted sampling of exceptions
Targeted samples focus on deviations: overdue remediation, failed backups, unauthorized access, or reopened tickets. These samples are not statistically representative of the whole population, but they are essential to assess escalation, accountability and follow-up processes.
Practical trade-offs when deciding sample size
Sample size should not follow habit. A sample of three may suffice for an annual control with three documented events, but would be inadequate for a daily process with hundreds of tickets. Conversely, checking twenty records all from the same month, system and owner adds little assurance.
Tie sample size to four factors: control frequency, associated risk, temporal distribution and historical quality of evidence. If a control is new or has prior findings, increase coverage. If it is stable, automated, and produces reliable audit trails, focus the sample on consistency, exceptions and completeness.
A useful rule is to combine breadth and depth: breadth covers different periods, locations, systems, teams or suppliers; depth traces a single case from creation to closure, validating approvals, logs, remediation and ownership. A small, deep sample often reveals more than many unrelated artifacts.
Operational criteria for selecting evidence
A robust sample avoids both “showcase selection” (only perfect cases) and purely random picks when risk is uneven. Combine temporal coverage, risk/asset coverage, diversity of owners and inclusion of exceptions.
Temporal coverage
If the audit covers twelve months, don’t limit yourself to the most recent period simply because those documents are easier to find. Select items from the start, middle and end of the period, and include moments such as migrations, supplier changes or major incidents to demonstrate continuity rather than last-minute preparation.
Risk and asset coverage
Critical systems must appear in the sample. If your perimeter includes identity, backup, logging, vulnerability management and suppliers, your sample should reflect those domains. For NIS2-relevant environments, map controls to operational evidence—reviews, tests, incident timelines and vendor assessments. See additional suggestions in /en/blog/nis2-audit-controls-evidence.
Owner coverage
A sample made up of artifacts from a single team doesn’t show whether the control model is distributed. Include owners across IT operations, security, procurement, privacy/legal, service owners and vendor management to validate that responsibilities are understood and approvals are traceable.
Exceptions included
Mature audits don’t hide exceptions. If there are late patches, failed restores, unauthorized accesses, or outstanding vulnerabilities, include some of those cases and show how they were handled. Compliance does not mean absence of problems—it means the ability to detect, assign and close them.
Record a sampling memo — traceability matters
The provenance of a sample is often more important than any single attachment. If an auditor cannot see from which population records were taken, why they were selected and who approved the extraction, the evidence loses strength. Prepare a concise sampling memo linked to the control under review.
A sampling memo should include: population description, period, source system/register, extraction method, risk criteria, owner of the selection and the freeze date of the sample. When possible, keep an export of the full population alongside the selected items to prove the sample wasn’t assembled after reviewing outcomes.
Suggested fields for a sampling memo:
- Control under review — connects sample to the verification objective
- Population size and description — shows the full scope
- Source and export timestamp — proves origin
- Selection method — documents the logic used
- Inclusion criteria — avoids arbitrariness
- Selector/owner and date — assigns responsibility
- Outcome summary — links sample to findings or remediation
Follow audit trail best practices: versioning, timestamps, user identities, recorded changes and explicit links between evidence, control and findings. See /en/blog/audit-trail-best-practices for more details.
Handling missing, inconsistent or untraceable evidence
An audit sample will often reveal anomalies. The objective is to classify and handle them, not to erase them from the record. Missing evidence suggests either the control was not performed or the proof wasn’t retained. Inconsistent evidence indicates conflicts between sources—e.g., a ticket marked closed while a vulnerability remains open. Untraceable evidence cannot be linked to an owner, time, system or requirement.
Each anomaly should lead to an operational outcome: no action if the explanation is documented and acceptable; a request for clarification if context is missing; a finding if the control cannot be demonstrated; or remediation if processes or evidence retention need fixing. Remediation must include an owner, deadline, status and verification of closure. Without those elements, sampling is merely descriptive.
Avoid retroactive fixes without trace. If a document is added after the sample freeze, record what changed, who made the change and why. Transparency reduces the risk of disputes and increases credibility.
Example sampling matrix for ICT controls
Assume a perimeter that includes privileged access, backups, incidents, vulnerabilities and suppliers. The goal is not to collect one artifact per area, but to prove that key controls ran and issues were followed through to resolution.
- Privileged access: sample high-privilege cases, routine cases and exceptions. Verify request, approval, duration and revocation. Possible finding: access active beyond expiry.
- Backup and restore: sample tests from different periods and critical systems. Verify outcome, logs, restore validation and owner sign-off. Possible finding: test recorded but not validated.
- Incident management: sample incidents across severities. Verify timeline, classification, escalation and closure. Possible finding: missing evidence of internal notification.
- Vulnerability management: sample critical, overdue and closed findings. Verify prioritization, assignment, remediation and retest. Possible finding: closure without technical retest evidence.
- Suppliers: sample critical vendors and any recent contract changes. Verify risk assessments, SLAs and follow-up actions. Possible finding: no periodic review performed.
This matrix helps link risk, control, evidence and remediation. If you use evidence-first audit software, the value is not only in storing files but in keeping samples, owners, versions, outcomes and corrective actions connected.
Common mistakes to avoid
- Sampling only easily retrieved evidence: creates a convenient but not necessarily credible sample.
- Confusing quantity with quality: many attachments mean little if they aren’t tied to a control and period.
- Failing to freeze the population: changing the source while the audit is in progress makes it hard to explain what was actually verified.
- Treating sampling as a compliance silo: involve IT and security to validate sources, process owners to confirm operational meaning, and auditors to document the rationale so it’s not reliant on verbal explanations.
Frequently asked questions
Is random sampling always sufficient for an ICT audit? No. Random sampling is useful for large, homogeneous populations, but insufficient when risk is concentrated in critical systems, strategic suppliers, severe incidents or documented exceptions. Combine randomness with risk-based criteria in those cases.
Should I keep the full population export in addition to the sample? Yes, when possible. Saving the population export at the selection date helps demonstrate where the sample came from and reduces the risk that the selection looks arbitrary.
How do I handle a missing evidence item in the sample? Don’t immediately replace it with a better case. Log the anomaly, request clarification from the owner, check for the proof elsewhere and decide whether to open a finding or remediation. Replacing items without traceability weakens the sample.
Can sampling demonstrate legal compliance? Sampling can support operational demonstration of controls but does not substitute for legal analysis. Legal obligations, scope and liabilities should be assessed with appropriate professionals.
Turn your sample into a verifiable evidence pack
When preparing audits against NIS2, DORA or other frameworks, organize your samples, owners, evidence and audit trail into an evidence pack that links directly to controls and remediation. AuditReady can help structure that pack so you arrive at review time with connected proofs rather than folders to reconstruct after the fact. Learn more at /en/auditready/lp/nis2.
audit-ready evidence pack demo / not legal advice