Audit, Assurance and Compliance Guide

Most security teams spend more time producing audit evidence than any other governance activity, yet a clean report can still sit on top of an environment that a regulator or an attacker would judge very differently. Audit, assurance and compliance is the discipline of proving, to someone who does not have to take your word for it, that security controls exist, are designed sensibly and actually operate. This overview explains how the field fits together: the difference between an attestation, a certification and an internal audit, how evidence is gathered and tested, where programmes go wrong, and how they mature. It is written for security and compliance leads, internal auditors and CISOs who need a single map of the field, and it links every NHI Mgmt Group guide in the category for the detail.

Key takeaways

Assurance is about who is vouching, and how. A CPA firm's SOC 2 opinion, an accredited ISO/IEC 27001 certificate, a PCI DSS Report on Compliance and an internal audit report carry different weight because the assurance provider, the criteria and the testing rules differ.
Design is not operation. A point-in-time review shows a control exists; only testing across a period (a SOC 2 Type 2 window, ISO surveillance audits, continuous monitoring) shows it worked every time it had to.
Scope is the most important sentence in any report. Carve-outs, excluded subsidiaries, inherited cloud controls and complementary user entity controls decide what the opinion really covers, and readers who skip the scope section over-trust the result.
Access control produces most findings. Provisioning, removal, privileged access and periodic review dominate testing in SOC 2 CC6, ISO/IEC 27001 Annex A 5.15 to 5.18 and SOX ITGCs, and auditors now sample service accounts, API keys and other non-human identities alongside staff accounts.
Mature programmes test once and report many times. A unified control set mapped to each framework, with automated evidence, lets one test of a control satisfy SOC 2, ISO, PCI DSS and internal audit together.

What the field covers

The category spans every activity whose output is a judgement about controls, made by someone with enough independence for others to rely on it. In practice that breaks into five areas.

External attestation: an independent accountant reports on management's description of a system and its controls against defined criteria. The AICPA describes its SOC reports as "a suite of service offerings CPAs may provide" so that report users can assess the risks of outsourcing. SOC 1 covers controls relevant to customers' financial reporting, SOC 2 covers security, availability, processing integrity, confidentiality and privacy, and SOC for Supply Chain applies the same five areas to production, manufacturing or distribution systems.
Certification: an accredited certification body audits a management system or control set against a standard and issues a certificate. ISO/IEC 27001:2022 is the most widely used; sector and national schemes such as TISAX (automotive), Cyber Essentials (UK) and StateRAMP / GovRAMP (US state government cloud) follow the same pattern with their own criteria.
Compliance assessment: testing against mandatory or contractual requirements, such as PCI DSS v4.0.1 for anyone storing, processing or transmitting card data, or security rules in sector regulation. The output is a pass, fail or list of gaps rather than an opinion.
Internal audit: the third line of the organisation's own assurance model, reporting to the audit committee. Since 5 February 2026 the Institute of Internal Auditors (IIA) Cybersecurity Topical Requirement sets a minimum baseline for any internal audit engagement that covers cyber risk.
Evidence and monitoring operations: the day-to-day machinery that makes the other four possible, including control ownership, evidence collection, continuous controls monitoring, compliance calendars and regulatory change tracking.

What the field does not cover: setting the security strategy itself (security leadership and governance), deciding which risks to accept (risk management) and interpreting individual laws (regulations and frameworks). Audit and assurance test what those functions decided.

Core concepts

The same vocabulary recurs in every scheme, though each uses slightly different words for it.

Concept	What it means	Where you meet it
Criteria	The benchmark the controls are judged against	Trust Services Criteria (SOC 2), clauses 4 to 10 and Annex A (ISO/IEC 27001), the 12 PCI DSS requirements, control objectives you define (SOC 1)
Scope and boundary	The systems, locations, entities and period covered	SOC 2 system description, ISO ISMS scope (clause 4.3), PCI cardholder data environment
Design effectiveness	The control, if operated as described, would meet the criterion	SOC 2 Type 1, ISO stage 1 readiness, walkthroughs in SOX testing
Operating effectiveness	The control did operate as described throughout a period	SOC 2 Type 2, ISO stage 2 and surveillance audits, SOX ITGC testing
Population and sample	The full set of control instances (all joiners, all changes) and the subset tested	Every operating effectiveness test; an incomplete population invalidates the sample
Exception, deviation, nonconformity	A tested instance where the control did not work; ISO grades nonconformities as major or minor	SOC 2 section 4 results, ISO audit reports, PCI "not in place" findings
Carve-out and inclusive methods	Whether a subservice organisation's controls are inside the opinion or excluded	SOC 1 and SOC 2 reports relying on cloud providers
Complementary user entity controls (CUECs)	Controls the customer must operate for the vendor's controls to work	SOC 2 and SOC 1 system descriptions; often MFA, access reviews and key management on the customer side
Bridge letter	A management letter covering the gap between a report period end and today	Vendor risk reviews between SOC report cycles
Corrective action	A tracked remediation with root cause, owner and date	ISO clause 10.2, NIST SP 800-53 CA-5 Plan of Action and Milestones, IIA follow-up

Attestation, certification and audit compared

Question	SOC 2 attestation	ISO/IEC 27001 certification	PCI DSS assessment	Internal audit
Who performs it	Licensed CPA firm under AICPA standards	Accredited certification body	QSA, or ISA, or self-assessment (SAQ) depending on level	The organisation's own internal audit function, or a co-source partner
Output	Opinion plus system description and, for Type 2, test results	Certificate for a three-year cycle with annual surveillance	Report on Compliance or SAQ, plus Attestation of Compliance	Report and rated findings to the audit committee
What it judges	Controls against the Trust Services Criteria	The management system, with controls selected through risk treatment	Prescribed requirements, or the customised approach	Whatever the risk-based audit plan targets
Who reads it	Customers and prospects under NDA	Anyone; the certificate is public	Acquirers, card brands, customers	Board, audit committee, management
Typical weakness	Narrow scope and CUECs that shift work to the reader	A certified scope that excludes the risky parts of the business	Scope reduced by segmentation that is not tested well	Findings closed on management assertion

For testing technique, NIST SP 800-53A Rev. 5 gives assessment procedures for every SP 800-53 control and describes three methods, examine (documents, configurations, logs), interview (people) and test (exercising the mechanism). The same three methods sit, under different names, inside every external audit methodology. Management system auditing more generally is guided by ISO 19011, which ISO lists as revised in 2026, replacing the 2018 edition.

Main threats

The threats to an assurance programme are not attackers, they are the ways an assurance result stops matching reality. Each one below has a real cost: customers relying on a report that does not cover what they think, or a regulator finding what the auditors did not.

Scope gaming: drawing the boundary around the parts that pass. A certified data centre and a single product line can be accurate and still tell a customer nothing about the platform they actually use. Read the scope before the opinion.
Low-quality assurance: reports produced quickly and cheaply with little real testing. The AICPA has said publicly that it is looking into allegations about one compliance vendor's SOC practices, and it advises service organisations and CPA firms to evaluate SOC services thoroughly. Check the audit firm, the period and whether section 4 shows genuine sampling.
Population errors: testing a sample drawn from an incomplete list. If the joiner, mover and leaver population comes from the HR system, the contractors, service accounts and API keys that never appear in HR are untested by construction.
Shared responsibility blind spots: a vendor's clean report does not cover the customer's own configuration. The Snowflake Breach 2024 involved no vulnerability or breach of Snowflake's platform, according to Snowflake and Mandiant; the exposed customer accounts lacked MFA, credential rotation and network restrictions, exactly the kind of control that appears as a CUEC.
Point-in-time drift: controls that were in place during fieldwork and decayed afterwards. Annual evidence sprints encourage it; continuous monitoring exposes it.
Compliance mistaken for security: meeting the letter of a framework while risk lies elsewhere. In the Capital One Breach 2019, an over-permissioned cloud role turned a firewall misconfiguration into exposure of about 106 million people, and the US Office of the Comptroller of the Currency imposed an $80 million civil money penalty in August 2020 citing weaknesses in cloud risk management. Regulators judge outcomes, not certificates.
Findings that never close: remediation accepted on a management assertion, then reported as closed. The IIA Global Internal Audit Standards require internal audit to confirm that agreed actions are implemented.

Key controls by maturity

Most programmes move through three stages. The NHI Mgmt Group five-level maturity models use finer steps, but these three are enough to decide what to fix next.

Area	Foundational	Managed	Optimised
Control set	Controls written separately for each framework	One unified control library mapped to every framework in scope	Control library tied to risk register entries and tested on a risk-weighted cycle
Ownership	Compliance team owns everything	Named control owner per control, with a deputy	Owners attest quarterly; ownership changes are a governed event
Evidence	Screenshots gathered in the weeks before fieldwork	Evidence collected on a calendar into a central repository	System-generated evidence pulled by API, with integrity protection (AU-9) and retention rules (AU-11)
Testing	External auditor is the first tester	Internal pre-testing using the auditor's sampling rules	Continuous controls monitoring on full populations; sampling only where automation is impossible
Access evidence	Human user reviews only	Reviews include privileged and shared accounts	Reviews include every service account, API key, token and AI agent identity, each with an owner
Third parties	Collect vendor certificates	Read SOC reports for scope, exceptions and CUECs; track bridge letters	Map vendor CUECs to your own controls and test them
Issues	Findings tracked in email	Central issue log with root cause, owner and due date (CA-5)	Validated closure, trend reporting and lessons fed into control design (ID.IM-02)

How to build or reset a programme

Decide which assurance you actually need. List the customer, regulatory and contractual drivers. A SaaS vendor selling to US enterprises usually needs SOC 2 Type 2; one selling into Europe often needs ISO/IEC 27001 as well; card data brings PCI DSS; a listed company brings SOX ITGCs.
Fix the scope first. Draw the system boundary, list subservice organisations and decide carve-out or inclusive treatment before writing controls.
Build one control library. Write each control once, with owner, frequency, evidence and the framework references it satisfies. See the PCI DSS 4.0 to ISO 27001 Mapping Guide for a worked example of reuse.
Run a readiness assessment. Test design against each criterion, then pre-test operation on a small sample. The readiness checklists in this category give the item lists.
Start the observation period. For a SOC 2 Type 2 or an ISO stage 2, controls must run, and produce evidence, from day one of the period. A control introduced half way through produces exceptions for the first half.
Automate the highest-volume evidence. Access reviews, joiner and leaver tickets, change approvals and vulnerability scan results are the usual first candidates.
Remediate and retest. Log every exception with root cause; retest before telling anyone it is closed. If a new control breaks operations, roll back to the documented previous control and record the change, rather than leaving an undocumented gap.

Decision guidance

Type 1 or Type 2 first: a Type 1 unblocks sales quickly while the Type 2 window runs, but enterprise buyers will ask for the Type 2. Skip Type 1 if you can already show three to six months of operating evidence.
Automation platform or spreadsheets: under about a hundred controls and one framework, a well-kept spreadsheet and ticketing system can work. Several frameworks, frequent audits or many system integrations favour a compliance automation or GRC platform. See the Compliance Automation Guide.
Small versus large organisations: a small company should pick one framework, scope narrowly and grow; a large group needs a central control library and federated owners, or each business unit will reinvent the same controls.

Metrics that show the programme works

Exception rate: exceptions per control tested, by framework and by owner, trending down over successive periods.
Evidence automation rate: share of evidence items collected by system rather than by hand.
Repeat findings: findings raised again within two audit cycles; a high number means closure is not real.
Mean time to remediate: days from finding to validated closure, split by severity.
Identity coverage: share of non-human identities with an owner and included in access reviews.
Control reuse: average number of framework requirements each tested control satisfies.

Roles and ownership

Assurance works only when the people operating a control are not the only people judging it. Most organisations describe this with the IIA's three lines model: management owns and operates controls, a second line (risk and compliance) sets the framework and monitors, and internal audit gives independent assurance to the governing body.

Role	Owns	Typical failure
Board or audit committee	Oversight of assurance coverage and of significant findings	Receiving certificates as good news rather than reading scope and exceptions
Control owner (first line)	Operating the control and producing evidence	Owner left the company; control silently stopped
Compliance or GRC lead (second line)	Control library, framework mapping, audit logistics, regulatory change	Becoming the de facto operator of controls they should only monitor
CISO and security team	Security control design and technical evidence	Treating audit as a distraction and losing influence over scope
Internal audit (third line)	Independent testing and follow-up, per the IIA Standards and Topical Requirement	Auditing policy existence instead of control operation on critical assets
External assessor	Opinion, certificate or Report on Compliance	Limited to the scope management chose
Vendor risk team	Reading third parties' reports and mapping their CUECs	Filing reports without reading section 4

NIST SP 800-53 expects the same separation: CA-2 Control Assessments, with enhancement CA-2(1) Independent Assessors, and AC-5 Separation of Duties. NIST CSF 2.0 GV.RR-02 asks that cybersecurity roles, responsibilities and authorities are established, communicated, understood and enforced.

Where identity fits

Identity controls carry a disproportionate share of audit testing, and non-human identities are the fastest-growing gap. A service account created by a pipeline has no HR record, so it falls outside the joiner and leaver population; an API key with no owner cannot be reviewed; an AI agent acting on a user's behalf may not appear in any access review at all. Auditors increasingly ask for inventories with owners, last-use dates and permissions for these identities. Starting points: the Service Account Security Guide, the Segregation of Duties Guide and, for AI agents, the AI Agent Audit Trails for Regulators Guide.

Standards and frameworks

Standard or framework	Role in assurance	Key references
AICPA Trust Services Criteria (2017, revised points of focus 2022)	Criteria for SOC 2 and SOC 3; five categories: security, availability, processing integrity, confidentiality, privacy	Common criteria CC1 to CC9; CC6 logical and physical access
ISO/IEC 27001:2022 (with Amd 1:2024)	Certifiable ISMS requirements; Annex A reference controls	Clause 9.2 internal audit, 9.3 management review, 10.2 corrective action; A.5.35 independent review of information security; A.5.36 compliance with policies
ISO 19011	Guidance for auditing management systems and auditor competence	Audit principles, audit programme management
NIST SP 800-53 Rev. 5 and SP 800-53A Rev. 5	Control catalogue and assessment procedures	CA-2, CA-5, CA-7 Continuous Monitoring, AU-6, AU-12, AC-2, AC-6
NIST CSF 2.0	Outcome framework used as audit criteria for programme maturity	GV.PO-01 policy, GV.OV-01 oversight, GV.SC-07 supplier risk, PR.AA-05 least privilege and separation of duties, ID.IM-02 improvement from tests
PCI DSS v4.0.1	Mandatory requirements for account data environments	Requirements 1 to 12; future-dated requirements in force since 31 March 2025
IIA Global Internal Audit Standards and Cybersecurity Topical Requirement	How internal audit plans, performs and follows up cyber engagements	Topical Requirement issued 5 February 2025, effective 5 February 2026

Practitioner checklist

List every assurance obligation (customer, regulatory, contractual) with its owner and next due date.
Write down the scope of each report or certificate, including carve-outs, before work starts.
Maintain one control library mapped to every framework you report against.
Give every control a named owner, a frequency and a defined evidence artefact.
Build test populations from system sources, not HR alone, so service accounts and API keys are included.
Pre-test controls internally with the external auditor's sampling rules before fieldwork.
Read section 4 exceptions and CUECs in every critical vendor's SOC report, and map CUECs to your own controls.
Track every finding to validated closure, and report repeat findings to the audit committee.

Where to go next

New to Audit, Assurance and Compliance? These are the foundational guides to read first.

Start here

SOC 2 Guide: Type 1 and Type 2, the Trust Services Criteria, scoping, CUECs, exceptions and bridge letters.
SOC 2 Readiness Checklist: the item-by-item preparation list for a first or renewal report.
ISO 27001 Certification Guide: ISMS clauses, Annex A, the Statement of Applicability and the certification cycle.
ISO 27001 Certification Readiness Checklist: preparing for stage 1 and stage 2 audits.
Cyber Essentials Guide: the UK baseline scheme and its technical controls.
PCI DSS Readiness Checklist: preparing for a PCI DSS v4.0.1 assessment.
SOX IT General Controls (ITGC) Guide: access, change and operations controls tested for financial reporting.
Internal Audit for Cybersecurity Guide: planning cyber audits under the IIA Standards and Topical Requirement.
Audit Evidence and Continuous Controls Monitoring Guide: evidence quality, automation and full-population testing.
Compliance Automation Guide: what automation can and cannot collect, and how to deploy it.
Regulatory Change Management Guide: tracking and implementing new obligations.

Browse all Audit, Assurance & Compliance guides

Audit, Assurance and Compliance Guide: Security Audits, Attestations and Evidence