Internal audit of controls: documents to prepare
An internal audit of controls checks whether data protection and security measures work as designed, not only as documented. Preparation means assembling policies, access logs, risk assessments and prior audit records before the review starts. Missing files on day one add weeks to the timeline and often decide whether the audit closes clean or escalates into a formal finding.
Why the audit runs now
Organisations run this audit ahead of a certification cycle, after a security incident, or when a regulator asks for evidence that data protection and cybersecurity measures work in practice. The audit does not create new obligations. It tests whether controls that already exist perform as the policy says they should.
A clean result shortens every downstream process. A weak result triggers remediation, and remediation has its own clock, separate from the audit itself.
Documents to prepare
The list below covers the core file. Scope narrows or widens depending on which systems and processes fall under review.
| Document | Owner | Purpose |
|---|---|---|
| Data protection policy | Compliance lead | States the documented rules for handling personal data |
| Access control register | IT security | Confirms who can reach which system and why |
| Risk assessment log | Risk officer | Records identified risks and the mitigation applied |
| Incident response records | Security team | Shows how past incidents were actually handled |
| Prior audit reports | Audit owner | Gives a baseline for comparing this cycle to the last |
| Vendor and processor contracts | Procurement | Confirms third-party obligations match internal controls |
Where the controls under review touch source code held by a third party, the underlying arrangement follows its own document list — see Escrow set-up: documents to prepare. That file runs on a separate track and does not merge with the audit file.
Stages and timeline
- The compliance lead scopes the audit within the first week, naming which systems, processes and controls fall under review.
- The audit owner collects the documents above and assigns any gaps to a named owner with a fixed date.
- The auditor interviews control owners, testing what the documents describe against what actually happens day to day.
- The auditor samples transactions and access logs and checks them against the written policy.
- The auditor drafts findings, ranked by severity, with a proposed action attached to each one.
- Management signs off on remediation, or the finding is escalated to the board as a formal case.
Where the review touches cross-border payment flows, the same document trail later feeds into Tax clearance for royalty flows, though the two procedures run on separate timelines and do not share a sign-off.
Who decides
The compliance lead scopes the exercise and confirms it is complete. The audit owner runs the review end to end and drafts findings. Anything above the severity threshold set by the organisation goes to the board or the equivalent oversight body, which signs off on remediation within the period it sets itself. Regulatory follow-up, where a regulator triggered the audit in the first place, sits with that authority rather than with internal management.
Scenarios
If the audit is voluntary and runs ahead of certification, scope is usually narrower and the file overlaps with Certification readiness: documents to prepare, prepared as a parallel step rather than a substitute.
If the audit follows an incident, the file includes the incident record itself, and the timeline compresses from weeks to days because the trigger has already defined the scope.
If a dispute arises over who owns a specific control and that dispute escalates outside the organisation, the clock switches to a different procedure — see How main infringement action patent runs in practice for how that separate track is timed.
If the organisation issues tokens, the audit also picks up Reserve in token issuance: definition and use as an additional control to test, since reserve handling sits inside the same control map.
Limits
This page describes the preparation stage of an internal audit. It does not set the timeline or outcome of statutory certification, does not fix how a regulator scores the findings once they leave the organisation, and does not cover what happens once a finding turns into cross-border enforcement.
Verified
Reviewed within the current cycle by the data and security practice. No external statutory citation applies at this procedural level; the file above reflects internal audit practice rather than a specific legal text.
Related publications
Many organisations run Certification readiness: documents to prepare as the step that follows a clean audit result, using the same evidence base rather than starting a fresh file.
FAQ
How long does internal audit of controls take in practice?
A scoped, voluntary audit typically runs four to eight weeks from kickoff to signed-off findings, depending on how many systems fall under review. An incident-triggered audit compresses to days because the scope is already fixed by the trigger event.
Which documents are needed to start?
The audit owner needs the current policy, the access control register and the prior audit report before the first interview. Everything else in the table above can follow during the collection stage without stopping the clock.
What happens if a control owner does not respond?
The audit owner escalates to the named manager after a fixed grace period, usually five working days. A control with no owner response by the drafting stage is recorded as a gap in its own right, regardless of what the underlying control actually does.
Next step
Source code and dependency exposure is a control gap that surfaces late if nobody checks for it early — read When open source is found in the delivery in before this file is marked closed.