Audit Prima Parte: A Modern Preparation Guide for 2026

Most advice on audit prima parte still starts in the wrong place. It starts with folders, templates, and a scramble to prove that policies exist. That approach might satisfy a basic internal quality review, but it doesn't hold up in a modern regulated technology environment where resilience has to be demonstrated through evidence, not declared through paperwork.

A first-party audit remains an internal audit performed by the organisation on itself. Under UNI EN 19011 guidance summarised here, it is a planned activity used to verify how the organisation stands against its own processes and performance, and it may be carried out by suitably trained internal staff or external professionals. The mistake is treating that definition as permission to keep the audit superficial.

In practice, the first phase of preparation is a systems problem. You are not assembling documents for inspection. You are establishing whether each obligation can be traced to a control, whether each control has an owner, and whether each claim can be supported by verifiable evidence. If that foundation is weak, the audit turns into interpretation, negotiation, and delay.

Rethinking the Internal Audit Beyond the Checklist

Checklist-driven internal audits are a poor fit for regulated technology operations. They reward document presence, version control, and formatting discipline. They do not reliably show whether a control is working, whether evidence has integrity, or whether the organisation could defend that claim under scrutiny from a regulator, customer, or incident review team.

That gap is wider now because frameworks such as DORA and NIS2 raise the standard from policy review to operational proof. An internal audit still checks the organisation against its own rules. In practice, the first phase has become a technical verification exercise. The question is no longer whether a procedure exists. The question is whether the control can be traced to system behaviour, preserved evidence, and accountable ownership.

What the old model gets wrong

Traditional audit preparation still centres on artefacts. Teams gather policies, export screenshots, update control spreadsheets, and try to close obvious gaps before anyone starts asking questions. That work is not useless. It is incomplete.

A signed policy does not prove encryption is enabled in production. A screenshot from an admin console does not prove timing, continuity, or integrity. A spreadsheet can list control owners, but it does not create an evidentiary chain that survives challenge if logs are mutable, timestamps drift, or access rights are broader than the control design assumed.

The result is predictable. The audit becomes an argument about interpretation instead of a verification of operation.

A first-party audit earns its value when it tests systems and evidence, not when it stages document compliance.

This change in approach also matters outside a single regulatory context. A practical guide to Australian business audits is useful because it treats audit work as business assurance tied to actual operations. The same discipline applies here, but regulated IT adds a harder requirement. Evidence has to be defensible, not merely available.

Verification is the correct starting point

Strong internal audit teams start by defining what would count as objective proof for each claim. They decide which system records are authoritative, how those records are retained, whether they are tamper-evident, and who can access or export them without breaking chain of custody. That is where modern audit preparation begins.

Under DORA and NIS2, resilience claims often depend on exactly these details. Log integrity, privileged access history, backup test results, third-party dependency records, incident timelines, and configuration states all need to be tied back to controls in a way that can be checked. If the evidence layer is weak, the audit may still produce a report, but the organisation has learned very little about its true readiness.

Teams that want a sharper separation between risk decisions and audit proof usually benefit from a clearer model of risk and compliance responsibilities. Risk management decides which failures matter. Audit preparation decides how those decisions will be verified with evidence that can withstand review.

Defining Audit Scope and Ownership

Scope is where most internal audits become inefficient. Teams often begin with assets because assets are easy to list. Servers, databases, SaaS tools, endpoints. The list grows quickly, but it doesn't tell you what the audit is trying to verify.

A better starting point is the business system. If the audit includes customer authentication, payment processing, regulated reporting, or incident response, each of those systems already implies technology, people, decisions, and dependencies. That gives the audit a boundary that reflects how the organisation operates.

Start with systems, not inventory

A system-centred scope is more precise because regulation usually bites at the level of service and function. Under DORA, for example, organisations have to work across mandatory pillars including ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk management, and governance, as outlined in this DORA compliance checklist. Those aren't asset categories. They are operating domains.

When you define scope around systems, you can ask practical questions:

• Which services are critical to regulated operations?
• Which obligations attach to those services?
• Which teams run them day to day?
• Which suppliers support them?
• Which evidence should exist if the controls are working?

That produces a smaller but more meaningful scope than "all infrastructure in the production environment".

Ownership has to be explicit

Many audit delays come from one repeated exchange. Someone finds a gap, then asks who owns the control, who approves the policy, who can provide evidence, and who can sign off remediation. If those answers depend on meetings, the audit isn't ready.

A formal Piano di Audit Interno helps prevent that drift. The Regione Toscana guidance states that the internal audit plan must be defined and distributed to stakeholders at least one week before the audit begins, including execution dates, reference documents, and the personnel involved. That matters because a distributed plan does more than schedule interviews. It establishes who is expected to show up with authority and evidence.

Practical rule: If a control has no named owner, the audit should treat that as a gap even before testing starts.

An ownership matrix should cover three layers:

That matrix should be documented, circulated, and stable enough that auditors don't have to reconstruct governance during fieldwork. If you need a clean model, a responsibility assignment matrix reference is a useful way to structure the accountability layer.

Later in the preparation cycle, a short walkthrough like the one below can help align stakeholders before evidence collection begins.

Mapping Controls to Policies and Evidence

The engineering work starts when broad compliance language is translated into something testable. Most audit confusion comes from mixing up three separate things: policy, control, and evidence.

A policy states intent and authority. A control is the mechanism that implements that intent. Evidence is the record that lets another person verify that the control exists and is operating as expected. If any one of those layers is missing, the audit becomes argumentative because people start substituting one for another.

Build a traceable chain

Take a familiar requirement such as access control. Under DORA, entities must classify ICT assets based on criticality, implement access control using RBAC and least privilege, and apply encryption for data at rest and in transit, with compliance validated by technical evidence, as summarised in this Ostorlab checklist. That sentence already contains all three levels, but they need to be separated.

A clean mapping looks like this:

• Policy statement: Access to critical ICT assets must be restricted according to role and business need.
• Control design: Production database roles are assigned through RBAC groups, privileged access is approved, and privileged activity is logged.
• Evidence set: Current role mappings, approval records, configuration exports, and recent log samples showing access events.

This sounds straightforward until teams try to do it across dozens of requirements. Then the usual problems appear. Policies are too generic. Controls are described as intentions rather than mechanisms. Evidence is stored in unrelated locations and labelled inconsistently.

What works in practice

The easiest way to stabilise this is to create a simple relationship model rather than another document pack. Each requirement should be linked to one or more controls. Each control should be linked to a responsible owner, a review cadence, and one or more evidence objects.

That model should answer these questions quickly:

1. Which policy requires this control?
2. Where is the control implemented?
3. Who maintains it?
4. What evidence proves it?
5. How recent is that evidence?

If an engineer can't trace a requirement down to a live control, an auditor won't be able to trace it either.

A small table often reveals weaknesses earlier than a long narrative:

For teams that need a visual way to explain the difference between policy administration and actual control implementation, Freeform Company's compliance guide is a helpful reference.

Avoid the document trap

The wrong way to map controls is to ask every team for "all relevant documents". That produces volume, not traceability. The right question is narrower: "What evidence would let another person verify this control without relying on your explanation?"

That shift usually changes the evidence set immediately. Teams stop sending polished policies first and start pulling configuration records, review outputs, ticket approvals, and log extracts. That's the moment the audit prima parte becomes useful, because the exercise moves from collection to verification.

Establishing Your Evidence Management Process

Teams often treat evidence management as a filing task. In practice, it is a chain-of-custody problem.

An internal audit loses value the moment evidence can be edited without trace, exported without context, or uploaded with no record of where it came from. That risk matters more now because frameworks such as DORA and NIS2 push audits away from static document review and toward technical verification. A policy can describe resilience. Only system evidence can show whether the control operated, when it operated, and whether the record remained intact after collection.

Scattered evidence breaks in familiar ways. An engineer exports a configuration snapshot locally. A service owner pastes a screenshot into chat. A vendor sends a PDF with no date and no system reference. At review time, nobody can prove which file supported which control or whether the artefact still reflects the state of the system at the relevant point in time.

Treat evidence like a governed asset

A workable process assigns rules to every artefact. Each item needs a control reference, a named owner, a source system, a collection date, and a stored location with visible access history. Version control matters. Provenance matters more.

For higher-risk controls, I do not rely on filenames and folder discipline alone. I want an immutable or at least tamper-evident record of collection, plus enough metadata to reproduce the path back to the original system. If the audit concerns operational resilience, identity security, backup integrity, vulnerability management, or incident response, screenshots are usually weak evidence unless they are tied to a ticket, export, log record, or signed system output.


A practical evidence inventory usually tracks:

• Control reference: The exact control or requirement the artefact supports.
• Evidence type: Log export, configuration snapshot, attestation, ticket record, test result, signed report.
• Collection metadata: Who collected it, when, from which source system, and under which request.
• Integrity record: Version, checksum or equivalent integrity marker, and any restriction on later editing.
• Review status: Whether the artefact was checked for completeness, relevance, and time validity.

That is the difference between a repository and a process.

Third-party evidence needs controlled intake

Third-party evidence should enter the same controlled workflow as internal evidence. It cannot sit in inboxes until someone remembers to upload it.

DORA raises the bar here because firms need disciplined records for ICT third-party dependencies and credible technical support for resilience and vulnerability-related controls, as reflected in the regulation text itself in the official DORA regulation. That changes the role of vendor artefacts. SOC reports, penetration test summaries, service commitments, incident notifications, and security attestations become auditable inputs, not background reading.

The collection problem is usually procedural before it is technical. If the request is vague, suppliers send marketing material. If the upload path is insecure, the organisation creates a new control failure while trying to prove control coverage.

Use a stricter intake method:

• Define the request precisely: ask for named artefacts mapped to named controls.
• Set acceptance criteria: specify format, review period, issuing party, and minimum metadata.
• Record source context: capture who submitted the file, in response to which request, and on what date.
• Separate receipt from validation: a received file is not accepted evidence until someone checks integrity, scope, and relevance.

That discipline applies outside cyber regulations too. The mechanics are similar to the document and record controls described in Fleetalyse audit preparation advice, even though the evidence types differ.

Evidence quality depends on verifiability

More files do not improve audit readiness. Better evidence does.

A small set of current, attributable, technically verifiable artefacts will usually outperform a large archive of PDFs and screenshots. For modern first-party audits, the strongest evidence often comes from system-generated records with stable identifiers, export timestamps, approval trails, and integrity markers. Where the tool supports it, hash values or signed exports give reviewers a way to detect silent changes after collection. That is much closer to an engineering control than a paperwork exercise.

A documented method for maintaining evidence matters because readiness should not depend on a pre-audit scramble. This guide to organising audit evidence for traceability and review explains the operating model in more detail. The standard is simple. Evidence should be easy to retrieve, easy to test, and difficult to dispute.

Preparing the Audit Environment and Access

The audit environment's importance is often underestimated. If auditors have to request files one by one, wait for screenshots, or rely on live demonstrations in production systems, the organisation is signalling that evidence access is improvised. That creates friction and weakens confidence in control maturity.

The comparison isn't really between simple tools and advanced tools. It's between an ad-hoc workspace and a controlled workspace.

Shared drives versus a dedicated audit environment

A spreadsheet plus cloud storage can work for a very small scope. It is familiar, cheap, and quick to start. It also breaks down once multiple reviewers, control owners, and evidence types are involved.

A dedicated audit environment usually performs better because it can enforce structure rather than rely on discipline alone.

The key issue is access design. Auditors need enough visibility to verify controls independently, but they shouldn't receive broad access to production systems or unrelated sensitive material. That means the workspace should support read-only evidence review, role-based permissions, and a clear record of who accessed what.

Access control is part of the control story

Many organisations accidentally undermine their own audit when they prove they have access restrictions in policy, then share evidence through folders with inconsistent permissions and no reliable access history.

A proper audit workspace should support a few essential elements:

• Read-only auditor access: Reviewers can inspect evidence without editing it.
• Role separation: Control owners, reviewers, and auditors don't all need the same permissions.
• Access logging: The organisation can see which artefacts were viewed and by whom.
• Stable references: Evidence links don't change every time someone reorganises a folder tree.

The audit environment is itself evidence of governance quality.

A useful parallel appears outside IT compliance as well. Fleetalyse audit preparation advice shows the same operational principle in another regulated context: preparation improves when records are organised before review day and responsibilities are clear. The underlying lesson carries over. Order isn't cosmetic. It reduces interpretation risk.

Convenience doesn't replace accountability

Automation helps, but it doesn't remove the need for named decisions. Someone still has to approve scope, validate evidence, grant access, and close findings. Tools can shorten the path, yet the audit remains a governance exercise.

That distinction matters for AI as well. If AI is used to classify artefacts, suggest control mappings, or detect missing fields, it should be treated as a component inside the process. Human owners still need to review outputs, confirm context, and decide what enters the audit record. The system may assist. Responsibility stays with people.

Producing the Initial Gap Snapshot

A weak internal audit ends with a colour-coded score. A useful one ends with a falsifiable snapshot of control failure, evidence failure, and resilience blind spots. That matters more now than it did a few years ago, because frameworks such as DORA and NIS2 expect organisations to prove operational control, not just maintain a tidy document set.

The output at this stage should show where the assurance chain breaks under inspection. If a control exists only in a policy, that is a design claim. If it runs but leaves no reliable trace, that is an evidence problem. If the trace can be altered without detection, the issue is integrity, not filing discipline.

What the snapshot should show

The most useful format is usually a structured remediation register, not a maturity score. Leadership needs a list of failures that can be assigned, tested, and closed with proof.

A solid initial gap snapshot often groups findings into categories such as:

• Control design gaps: Requirements or policies that do not resolve to an implemented control.
• Ownership gaps: Controls, systems, or supplier dependencies without a named accountable owner.
• Evidence integrity gaps: Artefacts that are missing, stale, incomplete, weakly attributable, or stored in a way that does not preserve provenance.
• Resilience assurance gaps: Backups, incident processes, logging, failover, recovery testing, or third-party dependencies that are declared but not demonstrated.

That structure changes the conversation. Teams stop arguing about whether they are "at 78%" and start working through specific breaks in the control system.

For modern audit prima parte work, this is the point where document review becomes technical verification. A policy that says logs are retained is not enough. The snapshot should record whether retention settings can be verified, whether timestamps are trustworthy, whether exports are complete, and whether the collected evidence can be tied back to the system state at the time of review.

Who contributes determines what gets closed

A credible snapshot rarely comes from compliance working alone. Service owners understand scope boundaries. Security and infrastructure teams know how controls operate. Engineering teams can confirm whether enforcement lives in code, tooling, or manual procedure. Procurement or vendor managers hold the supplier evidence that often breaks first under DORA and NIS2 scrutiny.

If one of those groups is absent, the snapshot drifts toward paperwork instead of verification.

The previously cited Insic article on first- and third-party auditor competencies supports the broader point that internal audit quality depends on the mix of skills involved. The specific closure-rate figures often repeated elsewhere are better omitted here because they are not directly substantiated in that source.

A gap snapshot is useful only if another reviewer can inspect the same evidence trail and reach the same conclusion.

That standard is higher than "we found the file."

The right output is a remediation queue

Each finding needs three fields at minimum. An owner. A remediation action. A verification method.

Classifying the issue correctly also saves time. A design problem means the control is missing or badly defined. An operating problem means the control exists but does not run consistently. An evidence problem means the control may be working, but the organisation cannot prove operation with trustworthy records. An integrity problem means the record exists, but its origin, timestamp, or immutability cannot be relied on.

Those distinctions matter in practice. Teams often rewrite policy to fix what is really a telemetry problem, or collect screenshots to cover a control that should be evidenced by signed logs, immutable exports, ticket history, configuration state, or test results.

The result is not a polished scorecard. It is a defensible starting position grounded in verifiable evidence. That is what an internal audit should produce before formal review begins.

If you need a structured way to turn scope, ownership, controls, and evidence into an audit-ready foundation, AuditReady is built for that operating model. It helps regulated teams organise evidence, map policies to controls, manage third-party requests, and produce a clear gap snapshot without falling back on vague scoring.