A compliance audit is a structured review of whether an organisation meets defined requirements, such as laws, regulations, standards, contracts, internal policies, or control obligations. On paper, anyway. In practical terms, it tests not only whether documents exist, but whether controls are designed, evidenced, and operating against the audit criteria.
The most effective audits are run as a workflow: define scope, map requirements to controls, request evidence, test that evidence, document findings, report results, assign remediation, and validate closure.
What Is a Compliance Audit?
ISO describes an audit as a systematic, independent, documented process for obtaining and objectively evaluating verifiable evidence against defined audit criteria. That definition is useful because it separates an audit from an informal policy review. More precisely, it separates the audit process from a general review: an audit has criteria, evidence, evaluation, findings, and conclusions. ISO 19011
A compliance audit applies that discipline to compliance obligations. The criteria may come from a regulation, certification framework, customer contract, internal policy, industry standard, or control set. The evidence may include policies, records, approvals, system logs, screenshots, tickets, training records, vendor files, or interviews, depending on the scope.
Why Compliance Audits Matter
Compliance audits help teams identify gaps against defined requirements and create a basis for remediation. They also provide a documented view of whether controls are designed and operating as expected.
The business value is operational as much as regulatory. A well-run audit clarifies:
- which obligations were tested
- which controls support those obligations
- what evidence exists
- where controls failed or could not be proven
- who owns remediation
- what must be validated before closure
Poor audit operations create different risks: missing evidence, inconsistent testing, duplicated document requests, unresolved findings, unclear ownership, and weak readiness for the next review, at least in practical terms.
Main Types of Compliance Audits
Audit programmes may include first-party internal audits, second-party audits of external providers, and third-party certification or accreditation assessments. ISO 19011
| Audit type | Who usually performs it | What it evaluates | Common output |
|---|---|---|---|
| Internal audit or readiness review | Internal audit, compliance, risk, security, or an independent internal reviewer | Internal controls, policies, readiness, and gaps against defined criteria | Findings, action plans, readiness assessment |
| Supplier or customer audit | Customer, partner, procurement, vendor-risk, or another second party | Contractual, security, privacy, quality, or service obligations | Supplier findings, risk rating, required remediation |
| External certification or assurance audit | Independent assessor, certification body, regulator, or authorised third party | Whether specified requirements are met | Certification decision, assurance report, regulatory report, or formal findings |
Common audit categories include information security, privacy, financial controls, operational compliance, workplace health and safety, environmental obligations, contractual compliance, and industry-specific requirements. Frameworks such as SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, SOX, or WHS may be relevant in some contexts, but no single framework is universal.
Internal vs External Compliance Audits
Internal audits are useful for readiness, self-assessment, control improvement, and pre-audit preparation. Where practical, reviewers should not assess their own work, although specific independence rules depend on the framework, regulator, or audit programme.
External audits are used when the organisation needs independent assurance, certification, regulatory review, or customer-required validation. For example, ISO describes certification as written assurance from an independent certification body that a product, service, or system meets specified requirements; in some industries or arrangements, certification may be a legal or contractual requirement. ISO certification
The distinction matters, external assurance does not remove the organisation’s responsibility to prepare good evidence. External auditors still depend on clear scope, control ownership, reliable records, and timely remediation responses.
How to Run a Compliance Audit: The Practical Workflow
A compliance audit should be run as an end-to-end operating process, not a last-minute document collection exercise.
A practical workflow
1. Define the objective and scope
Start by deciding what the audit is meant to answer. For example:
- Are you testing a regulation, standard, contract, policy, process, system, business unit, or control area?
- What review period applies?
- Which locations, teams, systems, vendors, or records are included?
- Which risks justify the selected scope?
A practical audit plan can link identified risks and controls to a defined testing approach. Where sampling is used, document the methodology, population, sample size, and any limits on projecting the results. IIA Global Internal Audit Standards
2. Map requirements to controls
Translate the audit criteria into internal controls. Each requirement should map to:
- the control that addresses it
- the control owner
- the system or process where the control operates
- the evidence expected
- the test to be performed
This prevents the audit from becoming a loose document hunt. It also helps expose gaps where a requirement has no clear owner or no operating control.
3. Prepare the audit plan
Before evidence collection begins, confirm:
- stakeholders and responsibilities
- audit timeline and communication cadence
- evidence request list
- sampling approach, if relevant
- expected evidence format
- criteria for sufficient evidence
- process for questions, exceptions, and delays
Defining evidence expectations early reduces rework. It also helps control owners understand that a policy document alone may not prove that a control operated during the review period.
4. Collect evidence
Evidence should be tied to the requirement, control, owner, audit period, and testing objective. Depending on scope, it may include policies, access records, configurations, logs, approvals, change tickets, training records, vendor assessments, incident records, or monitoring outputs.
Use a single evidence log where possible. Record who provided the evidence, when the evidence was received, what requirement it supports, and whether it has been tested.
5. Test evidence and control operation
Collecting evidence is not the same as testing it. For a control assessment, evidence should relate directly to the requirement being tested, fall within the assessment period, and be sufficient for the assessor to form a conclusion about the control. PCI SSC FAQ 1566
Testing may include examining records, interviewing control owners, and testing the control in practice. NIST assessment guidance, for example, recognises examination, interview, and testing as assessment methods, depending on the requirement. NIST SP 800-171A Rev. 3
6. Document findings
A finding should explain what was expected, what was observed, why it matters, and what should happen next. GAO guidance describes a well-developed finding as one that explains the relevant criteria, observed condition, cause, and actual or potential effect, with detail appropriate to the audit objective. GAO FISCAM
Avoid vague findings such as “access reviews need improvement.” A useful finding says which requirement was tested, what evidence was missing or failed, the risk created, the likely cause, and who needs to act.
7. Report results
The report should make the audit understandable to leadership, control owners, and future auditors. It should state what was tested, what was not tested, what failed, what risk remains, and what actions have been agreed.
8. Track remediation and validate closure
A finding is not closed just because a task is marked complete. Before closure, retain evidence that the agreed action was implemented and perform follow-up analysis or testing where the risk warrants it.
For internal-audit engagements, IIA standards state that final communication includes objectives, scope, conclusions, and applicable recommendations or action plans; assurance communications also address findings, significance or prioritisation, and scope limitations. They also call for follow-up communication to confirm action plans are implemented. IIA Global Internal Audit Standards
What Evidence Should You Collect and Test?
The right evidence depends, basically, on the audit scope. The goal is not to collect every possible artefact; it is to collect enough reliable evidence to support a conclusion about the requirement or control being tested.
Assess whether evidence is:
- relevant to the requirement
- within the review period
- traceable to a reliable source
- complete enough for the test
- consistent with system-of-record data
- attributable to the right owner, system, or process
Illustrative evidence requests, depending on scope
| Area being tested | Example evidence | What to test |
|---|---|---|
| Policies and procedures | Approved policies, procedures, standards, review history | Current approval, scope fit, review date, alignment with tested requirement |
| Access control | User listings, access approvals, access reviews, termination records | Whether access was approved, reviewed, removed, and appropriate during the period |
| Change management | Change tickets, approvals, test records, deployment logs | Whether changes followed the required workflow before release |
| Risk management | Risk register, assessments, treatment plans, review records | Whether risks were assessed, owned, treated, and reviewed |
| Incident management | Incident logs, response records, post-incident reviews | Whether incidents were recorded, escalated, resolved, and reviewed |
| Training | Training materials, attendance records, completion reports | Whether required personnel completed relevant training in the period |
| Vendor management | Contracts, service agreements, vendor assessments, external reports | Whether vendors were assessed and monitored according to the requirement |
| System configuration | Configuration exports, screenshots, baselines, monitoring records | Whether settings match the expected control state |
| Approvals and exceptions | Approval records, exception logs, expiry dates | Whether exceptions were authorised, time-bound, and reviewed |
| Monitoring or review controls | Logs, review sign-offs, alerts, dashboards, meeting records | Whether monitoring occurred and exceptions were followed up |
Documentation may prove that a process exists. It does not always prove the control operated. For example, an access review policy shows intent; completed review records, sampled user access, and evidence of revoked inappropriate access show operation.
How to Prioritise Findings and Manage Remediation
Findings should move through a controlled lifecycle: record, rate, assign, remediate, validate, and close.
At minimum, each finding should identify the criterion, observed condition, evidence, risk or effect, likely cause, severity, owner, target date, remediation plan, closure evidence, and validation status where appropriate.
Example finding and remediation tracker
| Field | What to record |
|---|---|
| Finding ID | Unique reference for tracking |
| Requirement or criterion | The policy, standard, contract, or control requirement tested |
| Condition | What was observed |
| Evidence | Records reviewed, samples tested, or evidence missing |
| Risk or effect | Actual or potential consequence |
| Root cause | Why the issue occurred, where known |
| Severity | Rating based on the organisation’s risk methodology |
| Accountable owner | Person responsible for remediation |
| Target date | Agreed remediation date |
| Management response | Accepted action, alternative treatment, or risk decision |
| Remediation plan | Specific corrective steps |
| Closure evidence | Proof that the agreed action was implemented |
| Validation status | Not started, in progress, implemented pending validation, validated, closed |
Severity should be documented rather than improvised. A simple model may consider:
- likelihood of recurrence
- impact if the control fails
- exposure period
- affected systems, customers, data, or processes
- whether the issue breaches a key obligation
- whether compensating controls exist
- whether the issue is isolated or systemic
Use the organisation’s risk methodology where one exists. If a finding is high risk, has no owner, or misses its target date, define an escalation path before the audit closes.
What Should a Compliance Audit Report Include?
A report does not need to be long to be useful. It needs to be clear enough for a reader to understand the scope, work performed, results, decisions, and next actions.
Practical report checklist
| Report component | Purpose |
|---|---|
| Executive summary | Briefly state overall result, major risks, and required action |
| Audit objective | Explain what the audit was designed to determine |
| Scope and period reviewed | Define included systems, teams, processes, locations, and dates |
| Criteria or requirements tested | Identify the standards, policies, contracts, or controls used |
| Methodology | Describe evidence review, interviews, sampling, and testing approach |
| Evidence sources | Summarise the main records and systems reviewed |
| Limitations | State exclusions, unavailable evidence, sampling limits, or constraints |
| Findings and severity | Present each finding with rating and supporting evidence |
| Risk implications | Explain why findings matter |
| Management response | Record agreed actions, accepted risks, or alternative plans |
| Owners and due dates | Make accountability visible |
| Remediation plan | State corrective actions and milestones |
| Follow-up or validation plan | Explain how closure will be confirmed |
| Appendices | Include detailed evidence references where useful |
The report should avoid unsupported conclusions. If evidence was incomplete, say so. If the audit did not cover a system, location, or period, make that limitation explicit.
When to Use Internal Teams, External Auditors, or Software
Use internal teams for readiness reviews, recurring control checks, evidence preparation, and improvement work. Internal teams are often closest to the processes being tested, but reviewer independence should be considered where practical.
Use an external assessor where the applicable scheme, regulator, contract, or customer requires independent assurance. External review may also be appropriate where leadership needs an independent view of a high-risk area.
Use software when audit work starts getting hard to manage through spreadsheets, shared drives, email threads, and one-off evidence folders. At that point, it gets messy pretty quickly. Software can help organise evidence requests, control mappings, reminders, dashboards, remediation status, and audit history. It does not replace auditor judgement or independent assurance.
Ciphrix’s operating perspective fits this model: compliance work is easier to manage when controls, evidence, findings, owners, and remediation status are maintained as a repeatable workflow rather than rebuilt for each audit.
How to Make Compliance Audits Repeatable
The best audit leaves the organisation more prepared for the next one.
To make audits repeatable:
- maintain a control register mapped to obligations
- keep evidence linked to controls and review periods
- record evidence owners and systems of record
- review previous findings before setting the next scope
- track remediation and closure evidence in one workflow
- confirm overlapping requirements carefully before reusing evidence across frameworks
- keep audit history accessible for future reviewers
Where requirements overlap, teams may be able to reuse underlying evidence, but they should still confirm each framework’s scope, wording, period, and assessor expectations.
Treat the audit as part of ongoing governance, not a recurring scramble. The practical measure of success is not just a completed report; it is cleaner evidence, clearer ownership, validated remediation, and a stronger starting point for the next review.