Compliance Audit
Also known as: audit, external audit, internal audit, security audit, compliance review
A compliance audit is a formal, independent examination of an organization's processes, controls, documentation, and practices to determine whether they meet the requirements of a specific regulation, standard, contract, or internal policy.
Audits produce findings -- gaps between what is required and what actually exists -- and organizations must respond with remediation plans. Common compliance audits include SOC 2 audits (against AICPA Trust Service Criteria), ISO 27001 audits (against ISMS requirements), PCI DSS assessments (against the DSS standard), and internal audits against organizational policies.
Compliance Audit, explained at three levels
At home
A compliance audit is when an independent expert checks whether your organization is actually following the rules it is supposed to follow. This might be an auditor checking that your financial controls meet SOX requirements, a certifier checking that your security practices meet ISO 27001 standards, or an internal team checking that your processes match your own policies. The auditor reviews documents, interviews staff, tests systems, and produces a report listing what passes and what fails.
At work
A compliance audit provides assurance -- to customers, regulators, boards, or investors -- that an organization's controls are in place and working as intended. The audit process includes: planning (defining scope and audit criteria), fieldwork (gathering evidence, conducting interviews, testing controls), reporting (documenting findings and their severity), and follow-up (verifying that remediation was completed). Findings are classified by severity -- a material weakness, a significant deficiency, or a control deficiency -- each carrying different disclosure and remediation obligations.
At home
Audits differ by independence level: internal audits are conducted by employees who are independent of the function being audited (the internal audit department); external audits are conducted by an independent third party (a certification body, licensed CPA firm, or specialist assessor). External audits carry more weight with regulators and customers because the independence is structural, not organizational. For ISO 27001, external audits are required for initial certification and recertification every three years.
At work
Compliance audits use sampling -- testing a representative subset of evidence rather than every instance of a control. For example, a SOC 2 auditor testing whether access reviews are performed might sample 25 access review records from the 12-month observation period rather than reviewing all records. If the sample reveals exceptions (controls that failed), the auditor expands the sample to understand the extent of the problem. A zero-exception sample from a reasonable sample size supports a clean opinion; exceptions trigger expanded testing and potential findings.
At home
The audit lifecycle follows a standard pattern: engagement letter (defining scope, timing, fees), pre-audit questionnaire (organization provides initial documentation), fieldwork (typically 2-5 days on-site or remote for mid-size organizations), draft report (organization reviews and responds), management response (organization documents its plan to address each finding), and final report (issued with management responses included). For certification audits, the certifying body or CPA firm issues the certificate or attestation report if no material issues prevent it.
At work
From a practitioner standpoint, audit readiness is best achieved through continuous compliance monitoring rather than a 'fire drill' before each audit. Organizations that maintain audit evidence throughout the year -- screenshots, access logs, training records, change tickets, policy acknowledgements -- spend significantly less time on audit preparation and have lower finding rates. Gap assessments conducted 3-6 months before a certification audit allow time to remediate significant gaps without the pressure of an active audit clock.
Real-world examples
At home
Lena's small accounting firm was required by its professional body to pass an annual compliance audit covering client data handling, access controls, and professional insurance. The auditor reviewed her policies, sampled client files for proper classification, and verified staff had completed annual privacy training. Two findings required a remediation plan but did not affect her membership status.
At work
Brightfield Bank's internal audit team conducted a quarterly compliance audit of the PCI DSS controls covering their e-commerce payment system. The audit sampled access review records, tested whether patches had been applied within the 30-day SLA, and reviewed firewall change records. A High finding -- two servers had not received the last critical patch -- was escalated to the CISO with a 15-day remediation deadline.
How it compares
| Feature | Compliance Audit | Risk Assessment | Penetration Test |
|---|---|---|---|
| What it examines | Whether controls meet specified requirements | Whether risks are identified and managed appropriately | Whether technical defenses can be exploited |
| Conducted by | Internal audit team or external auditor | Risk management team or external consultant | Ethical hacker / security firm |
| Output | Audit report with findings and recommendations | Risk register or risk report | Penetration test report with exploited vulnerabilities |
| Evidence basis | Documents, interviews, control testing samples | Interviews, workshops, threat intelligence | Active exploitation of live systems |
| Compliance use | Required for ISO 27001, SOC 2, PCI DSS, SOX | Required for ISO 27001, NIST CSF | Required for PCI DSS, SOC 2, ISO 27001 |
A compliance audit verifies whether controls exist and work. A risk assessment identifies threats and vulnerabilities before controls are applied. A penetration test proves that technical defenses can or cannot be bypassed. All three are complementary parts of a comprehensive assurance program.
For analysts
In BA artefacts, compliance audit requirements generate a specific category of NFR: controls that must be auditable, evidence that must be collected, and processes that must be formally documented. When designing requirements for a system that falls within an audit scope, specify which control activities the system must support and what evidence (logs, reports, records) must be generated and retained. Useful practice: tag each requirement with the audit criterion it satisfies, so auditors can quickly map requirements to evidence during fieldwork. Useful NFR: 'The system must produce a monthly access certification report exportable in PDF and CSV format, signed-off by the system owner, to satisfy ISO 27001 Annex A control A.5.18 requirements.'
History & origin
Compliance auditing as a formal discipline traces its roots to financial auditing, which has existed since the 19th century with the professionalization of accounting. The creation of the Securities Exchange Commission (1934) formalized audit requirements for public companies. Information technology audit emerged as a distinct discipline in the 1970s with the founding of ISACA (Information Systems Audit and Control Association) in 1969 and the publication of COBIT (Control Objectives for Information and Related Technologies) in 1996. The SOX Act (2002) significantly elevated IT audit's profile by requiring auditors to assess IT controls supporting financial reporting.