IT risk assessment and the compliance audit: process and checklist

Answer first. An IT risk assessment estimates what could go wrong with information and systems, how likely and how harmful, and decides what to do. An IT security or compliance audit tests whether the controls that decision relies on exist and operate, against stated criteria, and reports the gaps. Run the assessment first; it sets the audit's scope.

IT security audit, IT compliance audit and IT risk assessment: which is which

The three terms are used as if they were interchangeable. They describe two activities, and the second has two flavours.

A risk assessment is the estimating activity. NIST SP 800-30 Rev. 1 defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event, typically a function of the adverse impacts if it occurs and the likelihood of occurrence, and risk assessment as the process of identifying, estimating and prioritizing information security risks (section 2.3). The output is a prioritized list of risks with a response decision for each. Nothing is tested; the assessor judges.

An audit is the testing activity. ISO/IEC 27001:2022 clause 9.2.1 requires internal audits at planned intervals to show whether the management system conforms to the organization's own requirements and to the standard, and is effectively implemented and maintained. ISACA's IT Audit Framework (ITAF), 4th edition, calls its standards mandatory requirements that set the minimum level of acceptable performance. An auditor gathers evidence, compares it with criteria and reports.

The two audit flavours differ only in the criteria:

IT security audit, IT compliance audit and IT risk assessment: which is which

	IT risk assessment	IT security audit	IT compliance audit
Question answered	What could harm us, how likely, how badly, and what should we do?	Do our security controls exist and operate as designed?	Do we meet a named external requirement set?
Criteria	The organization's own risk criteria (ISO/IEC 27001:2022 6.1.2 a)	The organization's policies and a chosen control catalog (CIS Controls v8.1, ISO/IEC 27001:2022 Annex A, NIST SP 800-53 Rev. 5)	A regulation, contract or framework (PCI DSS, SOC 2, ISO/IEC 27001 certification, HIPAA Security Rule)
Who does it	Risk owners with the security or risk function	Internal audit, or a security team acting as second line	Internal audit before the external assessor, then the assessor
Output	Risk register entries, treatment plan, acceptance decisions	Findings with ratings and remediation actions	Findings plus a conformity statement or gap list against each requirement
Standard for the process	NIST SP 800-30 Rev. 1; ISO/IEC 27005:2022	ITAF, 4th edition; ISO/IEC 27001:2022 9.2	ITAF, 4th edition; the requirement set's own assessment procedure

The order matters. The assessment tells the audit which controls carry the most risk and so deserve the deepest testing; the audit tells the next assessment which controls it can no longer rely on. RCSA vs Risk Assessment vs Control Testing draws the same boundary for the wider GRC program, and What is cyber risk assessment? and What is compliance audit? define the terms.

The standards that require both, and where

Four families of standard require an organization to assess IT risk and to audit the resulting controls. Knowing the clause lets you answer an auditor's "where does it say that?" without a search.

ISO/IEC 27001:2022 (third edition, October 2022) requires a risk assessment process in clause 6.1.2 that establishes risk acceptance criteria and criteria for performing assessments, produces consistent, valid and comparable results, identifies risks to confidentiality, integrity and availability and their risk owners, analyses consequences, realistic likelihood and levels of risk, and evaluates the results against the criteria to prioritize treatment. Clause 8.2 requires the assessment to be performed at planned intervals or when significant changes are proposed or occur, and the results retained. Clause 9.2 requires internal audits (9.2.1) and an audit program with frequency, methods, responsibilities, planning requirements and reporting (9.2.2). Annex A lists 93 controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological, derived from ISO/IEC 27002:2022. See the ISO/IEC 27001:2022 framework page.

ISO/IEC 27005:2022 (fourth edition, October 2022) is the how-to for clause 6.1.2. Its foreword says the guidance was aligned with ISO/IEC 27001:2022 and ISO 31000:2018, that risk scenario concepts were introduced, and that the event-based approach to risk identification is contrasted with the asset-based approach. Clause 7 covers the assessment (7.2 identifying, 7.3 analyzing, 7.4 evaluating), clause 8 the treatment through to the Statement of Applicability (8.5) and acceptance of residual risk (8.6.3), and Annex A gives example techniques. See the ISO/IEC 27005:2022 framework page.

NIST CSF 2.0 (NIST CSWP 29, 26 February 2024) organizes outcomes into six Functions, Govern, Identify, Protect, Detect, Respond and Recover, and 22 Categories. Risk assessment is the ID.RA Category: internal and external threats identified and recorded (ID.RA-03), potential impacts and likelihoods of threats exploiting vulnerabilities identified and recorded (ID.RA-04), threats, vulnerabilities, likelihoods and impacts used to understand inherent risk and inform prioritization (ID.RA-05), and risk responses chosen, prioritized, planned, tracked and communicated (ID.RA-06). The Govern Function adds GV.RM-06, a standardized method for calculating, documenting, categorizing and prioritizing cybersecurity risks, and GV.OV Oversight, where audit results feed back. The CSF also gives the audit a target: the gap between a Current Profile and a Target Profile becomes an action plan such as a risk register or plan of action and milestones (section 3.1), and Tiers 1 to 4 (Partial, Risk Informed, Repeatable, Adaptive) describe how rigorous the practices are (section 3.2, Appendix B). See the NIST CSF 2.0 framework page and NIST CSF 2.0 and Connected GRC.

COBIT 2019 defines 40 governance and management objectives in five domains: Evaluate, Direct and Monitor (EDM); Align, Plan and Organize (APO); Build, Acquire and Implement (BAI); Deliver, Service and Support (DSS); and Monitor, Evaluate and Assess (MEA). Risk sits in APO12 Managed Risk (APO12.02 Analyze risk; APO12.03 Maintain a risk profile). Assurance sits in MEA: MEA01 Managed Performance and Conformance Monitoring, MEA02 Managed System of Internal Control, MEA03 Managed Compliance With External Requirements and MEA04 Managed Assurance, whose practices MEA04.08 and MEA04.09 cover reporting on the assurance initiative and following up on recommendations. Process capability is measured on a 0 to 5 scale. See the COBIT 2019 framework page.

For the assurance angle, the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) are the criteria a SOC 2 examination tests against; the section on SOC 2 attestation below covers it. SOC 2 vs ISO 27001 vs NIST explains how to build one control set that satisfies all three.

The NIST SP 800-30 risk assessment process, step by step

NIST SP 800-30 Rev. 1 (September 2012) remains the most detailed public description of how to assess information security risk. Chapter 3 organizes the work into four steps and 15 tasks. The table gives each task, the output to record, and where the same work appears in ISO/IEC 27005:2022 and NIST CSF 2.0.

The NIST SP 800-30 risk assessment process, step by step

Step	Task	What you record	ISO/IEC 27005:2022	NIST CSF 2.0
1 Prepare	1-1 Identify the purpose	The decision the assessment supports	6.1 Organizational considerations	GV.RM
1 Prepare	1-2 Identify the scope	Systems, time frame, architecture in scope	6.3 Applying risk assessment	GV.OC
1 Prepare	1-3 Identify assumptions and constraints	What is assumed about threats, controls, data	6.4 Establishing risk criteria	GV.RM-06
1 Prepare	1-4 Identify information sources	Threat intelligence, vulnerability scans, incident history, prior audits	7.1 General	ID.RA-02
1 Prepare	1-5 Identify the risk model and analytic approach	Scales, combination rule, quantitative or qualitative	6.5 Choosing an appropriate method	GV.RM-06
2 Conduct	2-1 Identify threat sources	Adversarial (individual, group, organization, nation-state) and non-adversarial sources with capability, intent and targeting	7.2.1 Identifying and describing risks	ID.RA-03
2 Conduct	2-2 Identify threat events	Events each source could cause, and their relevance	7.2.1	ID.RA-03
2 Conduct	2-3 Identify vulnerabilities and predisposing conditions	Weaknesses and conditions that raise likelihood, with severity	7.2.1	ID.RA-01, ID.RA-04
2 Conduct	2-4 Determine likelihood	Likelihood of initiation and of adverse impact, combined	7.3.3 Assessing likelihood	ID.RA-04
2 Conduct	2-5 Determine impact	Magnitude of harm to operations, assets, individuals, other organizations	7.3.2 Assessing potential consequences	ID.RA-04
2 Conduct	2-6 Determine risk	Level of risk from likelihood and impact, prioritized	7.3.4 and 7.4	ID.RA-05
3 Communicate	3-1 Communicate results to decision makers	The risk report and the response decisions it needs	10.3 Communication and consultation	ID.RA-06
3 Communicate	3-2 Share risk information	Distribution to those who own controls and systems	10.3	GV.RM-05
4 Maintain	4-1 Monitor risk factors	The indicators that would change a rating	10.5 Monitoring and review	ID.IM
4 Maintain	4-2 Update the assessment	Re-rated rows with the trigger recorded	9.1 Performing the assessment process	ID.RA-07

Two design choices in step 1 decide whether the output is usable. First, the risk model (Task 1-5): NIST section 2.3.2 says qualitative values must be defined with examples or different experts will produce significantly different results, and that repeatability improves when assessors record why they chose a value. Second, the approach to identification: ISO/IEC 27005:2022 distinguishes an event-based approach, which starts from risk sources and strategic scenarios, from an asset-based approach, which starts from assets, threats and vulnerabilities. An assessment that must feed an audit usually needs the asset-based approach, because audit tests attach to systems and controls.

The four steps are the same cycle the companion guide "Risk register and risk assessment matrix: how to build one (with template)" describes for enterprise risk; this guide keeps the IT-specific tasks and scales.

Threats, vulnerabilities, likelihood and impact: the scales

NIST SP 800-30 Rev. 1 publishes assessment scales in its appendices. Borrow them as written if you have none, and replace the descriptions with your own currency amounts, hours of downtime and record counts before you use them.

Threat sources (Appendix D, Table D-2) are adversarial (individuals, groups, organizations and nation-states, characterized by capability, intent and targeting) or non-adversarial. For adversarial sources, likelihood of initiation is rated on Table G-2; for non-adversarial sources, likelihood of occurrence on Table G-3, which carries frequency anchors: Very High occurs more than 100 times a year, High between 10 and 100 times, Moderate between 1 and 10 times, Low less than once a year but more than once in 10 years, Very Low less than once in 10 years.

Vulnerabilities are rated on Table F-2, which ties severity to the state of the control that should address them: Very High means the vulnerability is exposed and exploitable and no remediation is implemented or planned; High means remediation is planned but not implemented, with compensating controls at least minimally effective; Moderate means partially implemented and somewhat effective; Low means fully implemented and somewhat effective; Very Low means fully implemented, assessed and effective. That column is the bridge to the audit: an auditor's test of the control is what moves a vulnerability down the scale.

Likelihood is combined in two parts. Table G-4 rates the likelihood that a threat event, once initiated, results in adverse impact, and Table G-5 combines it with the likelihood of initiation to give an overall likelihood. The combination is a lookup, not a product:

Threats, vulnerabilities, likelihood and impact: the scales

Likelihood of initiation or occurrence ↓ / Likelihood of adverse impact →	Very Low	Low	Moderate	High	Very High
Very High	Low	Moderate	High	Very High	Very High
High	Low	Moderate	Moderate	High	Very High
Moderate	Low	Low	Moderate	Moderate	High
Low	Very Low	Low	Low	Moderate	Moderate
Very Low	Very Low	Very Low	Low	Low	Low

Impact is rated on Table H-3. High means a severe or catastrophic adverse effect, for example loss of a primary function, major damage to assets, major financial loss, or loss of life or serious injury. Moderate means a serious effect: primary functions continue with significantly reduced effectiveness, or significant damage, financial loss or harm to individuals. Low means a limited effect; Very Low means negligible.

Level of risk comes from Table I-2, another lookup. Very High likelihood with Very Low impact is Very Low risk; Low likelihood with Very High impact is Moderate; High likelihood with High impact is High. Each qualitative value also carries a semi-quantitative band (Very High 96 to 100, High 80 to 95, Moderate 21 to 79, Low 5 to 20, Very Low 0 to 4) and a 0 to 10 value, so the same scale works numerically.

ISO/IEC 27001:2022 does not prescribe any of this. Clause 6.1.2 a) asks for risk acceptance criteria and criteria for performing assessments; ISO/IEC 27005:2022 clauses 6.4.2 and 6.4.3 give guidance on both. The scales are the criteria. Version them, and stamp the version on every assessment.

A worked example: an unpatched remote-access appliance

Take one asset-based scenario through Tasks 2-1 to 2-6 using the NIST scales, then show what the audit tests afterwards.

Scenario (Task 2-2). An established adversarial group exploits a published vulnerability in the organization's internet-facing remote-access appliance to gain a foothold on the internal network.

Threat source (Task 2-1). Adversarial, organization or group, with the capability to weaponize published vulnerabilities and no specific targeting of this organization. On Table G-2 the assessor rates likelihood of initiation High: the adversary is highly likely to initiate the event, because exploitation of internet-facing appliances is opportunistic and does not depend on the target's identity. The reasoning goes in the rationale field.

Vulnerability and predisposing conditions (Task 2-3). The vendor patch has been available for longer than the policy's 14-day window for internet-facing systems and is not applied; the appliance accepts single-factor authentication; and it is reachable from any internet address. On Table F-2 this is High: remediation is planned but not implemented, and the compensating control (network intrusion detection) is at least minimally effective.

Likelihood (Task 2-4). Given initiation, the likelihood of adverse impact on Table G-4 is High, because an exploit against this class of device typically yields authenticated access. Table G-5, High row and High column, gives an overall likelihood of High.

Impact (Task 2-5). A foothold on the internal network exposes the organization's primary line-of-business systems and customer records. On Table H-3 the assessor rates impact High: severe degradation of a primary function and major financial loss are credible outcomes.

Risk (Task 2-6). Table I-2, High likelihood and High impact, gives High. The row is recorded with the scenario, the source, the vulnerability, both likelihood ratings, the impact, the level and the rationale for each value.

Response (ID.RA-06). The risk owner selects mitigation: apply the patch, enforce multi-factor authentication on the appliance, and restrict inbound access to known address ranges. After the actions close, the assessor re-rates. Likelihood of initiation stays High, since scanning continues regardless. Likelihood of adverse impact given initiation drops to Low, because the exploit no longer works and a stolen password alone no longer grants access. Table G-5, High row and Low column, gives an overall likelihood of Moderate. Impact is unchanged at High. Table I-2, Moderate likelihood and High impact, gives a residual level of Moderate. Whether Moderate is acceptable is a comparison with the risk acceptance criteria, recorded with the approver's name and date; Vulnerability Exceptions and Risk Acceptance covers the "not yet" case.

What the audit then tests. The residual rating rests on three controls: patching within 14 days for internet-facing systems, multi-factor authentication on remote access, and inbound address restriction. Those become audit test steps. The auditor asks for the patch policy, the scanner's report for the appliance dated after the patch, the authentication configuration export, the firewall rule set, and a sample of change tickets showing who approved the changes and when. If any of that is missing, the residual rating goes back to High until it is found: a rating that depends on an untested control is a hope, not an assessment.

From risk to audit scope: risk-based audit planning

ITAF standard 1201 Risk Assessment in Planning requires the IT audit function to use a risk assessment to decide what to audit, and standard 1202 Audit Scheduling to turn that into an overall plan with short-term and long-term schedules. ISO/IEC 27001:2022 clause 9.2.2 says the same in management-system language: when establishing the program, consider the importance of the processes concerned and the results of previous audits.

In practice the assessment output becomes the audit universe's risk ranking:

1. List the auditable entities. Systems, processes, business units, third parties and control domains. What is audit universe management? describes the record.
2. Attach the level of risk to each entity. An entity inherits the highest level among the scenarios that touch it. Where the assessment used the CSF, the Current-to-Target Profile gap is a second ranking input.
3. Add the audit-specific factors. Time since last audit, its results, change since then, regulatory attention and management concern. ITAF 1201 also asks the practitioner to consider audit risk, the risk that the audit itself reaches the wrong conclusion.
4. Set the depth, not just the selection. A High-risk entity gets a full operating-effectiveness test sampled across the period; a Low-risk entity may get a design review only.
5. Fix criteria and scope per engagement, as ISO/IEC 27001:2022 9.2.2 a) requires: which catalog, which systems, which period.

What is a risk-based audit plan? and Internal Audit Management in a Connected GRC Program cover the plan and its governance in more depth.

The IT audit process, from scope to follow-up

ITAF's performance and reporting standards define the engagement from planning to follow-up. The table walks the seven stages, the ITAF standard that governs each, and the artifact the stage produces.

The IT audit process, from scope to follow-up

Stage	What happens	Governing standard	Artifact
1 Scope	Define the objective, the systems and period in scope, the control catalog used as criteria, and the exclusions. Confirm the auditor's independence and objectivity.	ITAF 1203 Engagement Planning; 1002 Organizational Independence; 1003 Auditor Objectivity; ISO/IEC 27001:2022 9.2.2 a) and b)	Engagement memo or terms of reference, signed by the audit owner and the auditee's management
2 Criteria	Map each control in scope to the requirement it must meet and to the test that will show it operates. Criteria must be suitable and, where possible, published.	ITAF 1008 Criteria; 1007 Assertions	Audit program: one row per control with objective, test procedure and evidence expected
3 Evidence request	Issue the request list with owners and due dates, specifying document, configuration export, report, screenshot or log, and the population from which samples will be drawn.	ITAF 1205 Evidence	Request list with status; population files
4 Fieldwork	Perform the tests: inquiry, observation, inspection of documents and configurations, re-performance, and sampling across the period. Supervise and document as work proceeds.	ITAF 1204 Performance and Supervision; 1205 Evidence; 1206 Using the Work of Other Experts	Workpapers with test steps, evidence references, sample selections and results
5 Findings	Write each exception as condition, criteria, cause, effect and recommendation; rate it; agree facts with the control owner before the report. Consider whether any exception indicates irregularity.	ITAF 1207 Irregularities and Illegal Acts	Findings log with ratings and management responses
6 Report	Report the scope, criteria, conclusion, findings and agreed actions to the level of management that can act on them.	ITAF 1401 Reporting; ISO/IEC 27001:2022 9.2.2 c)	Audit report; summary for the audit committee
7 Follow-up	Track each action to closure, verify the fix with new evidence, and re-open the finding if the evidence does not hold.	ITAF 1402 Follow-up Activities; COBIT 2019 MEA04.09	Action tracker with verification evidence; closure memo

Stage 2 is where most audits are won or lost. A control with no stated test cannot fail, so it also cannot pass. The program should say, for each control, what "operating" looks like in evidence terms before anyone asks for anything. The checklist below gives that for 18 areas.

Stage 7 is where audits are quietly lost. ITAF 1402 exists because a finding without follow-up is an observation. What is audit follow-up management? covers the mechanics; How to Turn Audit Findings Into Risk Intelligence covers what the findings should change in the next risk assessment.

Evidence: what sufficient and appropriate means

ITAF standard 1205 Evidence requires the practitioner to obtain sufficient and appropriate evidence to support the conclusions. Sufficient is about quantity: enough items, over enough of the period. Appropriate is about quality: relevant to the assertion being tested and reliable in origin.

Four rules keep IT evidence appropriate:

• Prefer system-generated over person-generated. A configuration export, a scanner report or an access log is more reliable than a screenshot, and a screenshot is more reliable than an email saying the control ran.
• Date it and bound it. Evidence must show the period it covers. A user-access review dated after the audit period does not evidence the control during the period. What is evidence freshness and why does it matter? sets out the aging rules.
• Prove the population before the sample. A sample of 25 change tickets says nothing if the auditor cannot show that the 25 came from all changes in the period. Population Completeness in Control Testing and How to Choose Samples for Control Testing Without Weakening Assurance cover the method.
• Collect once, reuse many. A privileged-access export tested for the ISO/IEC 27001 internal audit is the evidence a SOC 2 examination and a PCI DSS assessment will ask for. Store it against the control, not the audit. How to Reduce Duplicate Evidence Requests Across GRC Teams and Evidence Management in GRC describe the evidence model.

Control owners can prepare with the Evidence Quality Checklist for Control Owners and the Control Owner Evidence Guide.

The IT audit checklist: 18 control areas and the evidence each expects

The table is an IT audit program in outline. The 18 areas follow the 18 Controls of CIS Critical Security Controls v8.1 (June 2024), because that catalog is written as things an organization does and so tests cleanly, and each row cross-references the ISO/IEC 27001:2022 Annex A control and the NIST CSF 2.0 Category that ask for the same thing. CIS v8.1 has 153 Safeguards across the 18 Controls; the Safeguards in Implementation Group 1, which CIS calls essential cyber hygiene, are the minimum an audit of a small entity should cover. The companion CSV holds the full rows with test procedures and sample bases.

The IT audit checklist: 18 control areas and the evidence each expects

#	Control area	What the auditor tests	Evidence expected	CIS v8.1	ISO/IEC 27001:2022 Annex A	NIST CSF 2.0
1	Enterprise asset inventory	An accurate inventory of hardware exists, is reconciled to discovery, and unauthorized assets are handled	Inventory export; discovery-tool reconciliation; handling records for unknown devices	Control 1 Inventory and Control of Enterprise Assets	5.9 Inventory of information and other associated assets	ID.AM
2	Software inventory	Only authorized, supported software runs; unsupported software is documented as an exception	Software inventory export; allowlisting configuration; exception register	Control 2 Inventory and Control of Software Assets	5.9; 8.19	ID.AM
3	Data classification and protection	Data is classified, sensitive data is inventoried, and handling, encryption and disposal follow the classification	Classification scheme; data inventory; encryption configuration; disposal records	Control 3 Data Protection	5.12 Classification of information; 8.24 Use of cryptography; 8.12 Data leakage prevention	PR.DS
4	Secure configuration	Baselines exist for operating systems, devices and cloud services, and deviations are detected and corrected	Baseline documents; configuration-compliance scan results; deviation tickets	Control 4 Secure Configuration of Enterprise Assets and Software	8.9 Configuration management	PR.PS
5	Account management	Accounts are provisioned on approval, reviewed periodically and removed on leaving; dormant accounts are disabled	Joiner, mover, leaver samples; access review sign-offs; dormant-account report	Control 5 Account Management	5.18 Access rights	PR.AA
6	Access control and privileged access	Least privilege applies, privileged accounts are separate and inventoried, and multi-factor authentication covers remote and administrative access	Privileged account inventory; MFA configuration export; role definitions; access review evidence	Control 6 Access Control Management	5.15 Access control; 8.2 Privileged access rights; 8.5 Secure authentication	PR.AA
7	Vulnerability management	Scanning runs on schedule, findings are risk-rated, and remediation meets the policy's time windows	Scan schedule and reports; remediation SLA policy; ticket samples showing time to fix; exception approvals	Control 7 Continuous Vulnerability Management	8.8 Management of technical vulnerabilities	ID.RA
8	Audit logging and monitoring	Logs are collected centrally, retained for the policy period, protected and reviewed; alerts are triaged	Logging configuration; retention settings; review or alert-triage records	Control 8 Audit Log Management	8.15 Logging; 8.16 Monitoring activities	DE.CM
9	Email and web protection	Filtering, DNS protection and attachment controls are in place and maintained	Gateway configuration; block-list update records; phishing simulation results if run	Control 9 Email and Web Browser Protections	8.7 Protection against malware; 8.23 Web filtering	PR.PS
10	Malware defenses	Anti-malware is deployed to all in-scope assets, updated and centrally managed	Coverage report versus asset inventory; signature update status; detection log samples	Control 10 Malware Defenses	8.7 Protection against malware	PR.PS
11	Backup and recovery	Backups run per schedule, are protected and isolated, and restores are tested	Backup job logs; restore test records with dates and outcomes; isolation configuration	Control 11 Data Recovery	8.13 Information backup; 5.30 ICT readiness for business continuity	RC.RP
12	Network infrastructure	Network devices are inventoried, securely configured, up to date and documented; segmentation matches the architecture	Device inventory; firmware versions; network diagram; firewall rule review records	Control 12 Network Infrastructure Management	8.20 Networks security; 8.22 Segregation of networks	PR.IR
13	Network monitoring and defense	Intrusion detection, traffic filtering and central alerting operate and are tuned	Sensor coverage; alert samples with triage outcomes; tuning change records	Control 13 Network Monitoring and Defense	8.16 Monitoring activities	DE.CM
14	Security awareness and training	All staff complete training at joining and on schedule; role-specific training exists for privileged users	Completion reports versus HR headcount; training content; role-specific records	Control 14 Security Awareness and Skills Training	6.3 Information security awareness, education and training	PR.AT
15	Service provider management	Providers are inventoried and classified, contracts carry security requirements, and providers are assessed and decommissioned on exit	Provider inventory; contract clause samples; assessment records; offboarding evidence	Control 15 Service Provider Management	5.19 Information security in supplier relationships	GV.SC
16	Application security and change	A secure development life cycle exists, code and dependencies are tested, and production changes are approved and traceable	SDLC policy; scan results; change ticket samples with approval and test evidence; emergency-change records	Control 16 Application Software Security	8.25 Secure development life cycle; 8.32 Change management	PR.PS
17	Incident response	A plan exists with roles, contacts and reporting thresholds; incidents are recorded, handled and reviewed; the plan is exercised	Incident response plan; incident register samples; post-incident reviews; exercise records	Control 17 Incident Response Management	5.24 Information security incident management planning and preparation	RS.MA
18	Penetration testing and independent review	External and internal tests run on schedule, findings are remediated, and the security program is independently reviewed	Test scope and reports; remediation tracking; independent review reports	Control 18 Penetration Testing	5.35 Independent review of information security; 5.36 Compliance with policies, rules and standards for information security	ID.IM

Two areas that CIS v8.1 does not carry as Controls belong on a full IT audit program and are in the CSV as rows 19 and 20: security governance and policy (ISO/IEC 27001:2022 Annex A 5.1 Policies for information security; NIST CSF 2.0 GV.PO) and physical security of IT facilities (Annex A 7.1 Physical security perimeters; NIST CSF 2.0 PR.AA). CIS v8.1's own change was to add a Governance security function to its mappings so that they align with NIST CSF 2.0, which is why the CSF's Govern Function is the better home for that row. See the CIS Critical Security Controls v8.1 framework page.

Findings, ratings and remediation

A finding is an exception between evidence and criteria. Write it in five parts so the reader can act without asking: the condition (what the evidence shows), the criteria (what should be true, with the clause or control reference), the cause (why the gap exists), the effect (the risk, expressed in the assessment's own terms) and the recommendation.

Rate it on the scale the risk assessment uses. If the assessment rated the scenario the failed control was meant to reduce as High, the finding is High until the fix is verified; separate scales are how audit and risk drift apart. Link the finding to the risk register row it affects, so the residual rating updates when the control fails, and to the action record that will fix it, with an owner and a due date. How Issues Management Becomes the Backbone of Connected GRC describes the action side; How Controls Connect Risk, Compliance, Audit, and Remediation describes the links.

Closure needs new evidence, not a statement. ITAF 1402 and COBIT 2019 MEA04.09 both make follow-up on recommendations a distinct activity. The person who verifies closure should not be the person who fixed it.

Internal audit, external audit and SOC 2 attestation

An IT audit run by internal audit, an audit run by an external certification body, and a SOC 2 examination are three different engagements with three different readers.

Internal audit, external audit and SOC 2 attestation

	Internal IT audit	External certification audit	SOC 2 examination
Who performs it	The organization's internal audit function or an outsourced provider acting for it	An accredited certification body (for ISO/IEC 27001) or qualified security assessor (for PCI DSS)	A licensed CPA firm
Criteria	The organization's policies and a chosen catalog	The standard's requirements and, for ISO/IEC 27001:2022, the Annex A controls in the Statement of Applicability	The AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) for the categories in scope: security, availability, processing integrity, confidentiality, privacy
Governing standard for the auditor	ITAF, 4th edition; ISO/IEC 27001:2022 9.2	The certification scheme's rules	The AICPA attestation standards and its SOC 2 guide
Output	Report to management and the audit committee	Certificate and nonconformity report	A report on the description of the system and on controls: Type 1 covers the design of controls at a point in time; Type 2 covers design and operating effectiveness over a period
Reader	Management, the board	Customers and regulators who accept the certificate	Customers who rely on the service organization's controls

The internal audit is the rehearsal for the other two. Run it against the criteria the external engagement will use and keep the evidence in one place; the external work then reviews what already exists. SOC 2 Compliance as a Connected Workflow and What is SOC 2 compliance in cybersecurity? cover the SOC 2 side; the SOC 2 framework page lists the criteria.

Cadence: how often to assess and how often to audit

The standards set triggers rather than intervals, and the two activities run on different clocks.

Risk assessment. ISO/IEC 27001:2022 clause 8.2 requires assessment at planned intervals or when significant changes are proposed or occur. NIST SP 800-30 Rev. 1 Step 4 asks for ongoing monitoring of risk factors and an updated assessment when they change. A workable rule: a full assessment annually, and a re-rating of affected scenarios whenever a new system goes live, a significant vulnerability is published for an in-scope product, an incident occurs, or an audit finding removes reliance on a control.

Internal audit. ISO/IEC 27001:2022 clause 9.2.2 leaves frequency to the program but requires it to reflect the importance of the processes and the results of previous audits. A common pattern covers every High-risk area annually and every other area at least once in the certification cycle. ITAF 1202 asks for both short-term and long-term schedules.

Continuous monitoring. Between audits, controls that produce system-generated evidence (scanning, access reviews, backup jobs, log collection) can be monitored continuously. That is not the same as auditing them; Continuous Compliance Is Not the Same as Continuous Control Monitoring explains why, and How to Build a Control Testing Calendar shows how to test one control once for SOX, SOC 2, internal audit and compliance.

Common mistakes

1. Auditing without an assessment. The program covers what is familiar rather than what is risky. ITAF 1201 and ISO/IEC 27001:2022 9.2.2 both require the risk assessment to drive the plan.
2. Assessing without anchored scales. "High" means different things to different assessors until it carries a frequency, a currency amount or a downtime figure. NIST SP 800-30 Rev. 1 section 2.3.2 names the remedy: defined values, examples and a recorded rationale.
3. Reducing residual risk for untested controls. Table F-2 makes the point in the vulnerability scale itself: only a control that is implemented, assessed and effective takes severity to Very Low.
4. Treating a screenshot as evidence of a period. It evidences a moment. Ask for the export, the log or the report that covers the period, and prove the population before sampling.
5. Rating findings on a different scale from risks. The audit committee then sees two pictures that do not reconcile. Use the assessment's scale and link the finding to the register row.
6. Closing findings on a statement. ITAF 1402 requires follow-up; verification means new evidence, reviewed by someone other than the fixer.
7. One catalog per audit. Testing the same access review three times for ISO/IEC 27001, SOC 2 and PCI DSS is the default failure of an unconnected program. How to Map NIST, ISO, SOC 2, SOX, CRI, and Internal Policies shows the alternative.
8. Stopping at the report. The assessment should change because of the audit, and the next audit plan because of the assessment. If neither moves, one is decorative.

How SmartSuite does this

SmartSuite's Cyber and IT Risk and Audit Management solutions hold both halves of this guide in one linked data model: a risk scenario, its controls, the tests of those controls, the evidence and the findings are records that reference each other.

• Cyber Threat Management captures threat intelligence from internal and external sources, classifies and prioritizes threats by severity, likelihood and business impact, tracks vulnerabilities across systems and applications, runs response workflows, and aligns threat scores with enterprise risk scoring. The product page lists alignment with NIST CSF and ISO 27001 and links threats to incidents, risks, issues, controls and vendors.
• Vulnerability Management (GRC) ingests scanner output into a system of record, prioritizes by asset criticality, exposure and business impact, correlates vulnerabilities with active threats, maps them to control requirements and compliance frameworks, and tracks unresolved items as issues with owners. That is the Table F-2 column in this guide, kept current from the scanner rather than re-keyed.
• Audit Management runs the seven-stage process above: planning and scheduling across business units and frameworks, workpapers with version control and traceability, fieldwork and testing with standardized procedures, findings with structured classification, remediation and action tracking, dashboards, workflow automation for approvals and escalation, and framework alignment. The product page references COSO, ISO and IIA standards.

Supporting products: Compliance Assessments & Testing for testing campaigns, Issues Management for findings and actions, Control Framework & Regulatory Libraries for the CIS v8.1, ISO/IEC 27001:2022, NIST CSF 2.0 and SOC 2 catalogs, and SOC 2 Compliance for the attestation cycle. For the roles, see Connected GRC for the CISO and Connected GRC for Internal Audit.

Template

The companion file it-audit-checklist-template.csv holds 20 rows, one per control area (the 18 above plus governance and policy, and physical security), with 18 columns. Import it as an audit program, or use it as the field list when you configure one in a GRC tool.

Template

Column group	Columns
Identity	area_no, control_area, audit_objective
Test design	test_procedure, evidence_expected, sample_basis
Criteria mapping	cis_v8_1_control, iso_27001_2022_annex_a, nist_csf_2_0_category
Execution	control_owner, evidence_received, test_result, workpaper_ref
Findings and follow-up	finding_id, finding_rating, remediation_owner, target_date, follow_up_status

The test_result column takes four values: Effective, Partially effective, Ineffective, Not tested. The finding_rating column should use the same scale as your risk assessment (the NIST five values in this guide). Fill sample_basis before fieldwork starts; it is the population statement the auditor will need to defend.

FAQs

What is the difference between an IT security audit and an IT risk assessment? The risk assessment estimates what could go wrong, how likely and how harmful, and decides on a response; nothing is tested. NIST SP 800-30 Rev. 1 describes it as identifying, estimating and prioritizing risk. The audit tests whether the controls the response relies on exist and operate, against stated criteria, and reports exceptions. ISO/IEC 27001:2022 keeps them in separate clauses, 6.1.2 and 9.2.

Which framework should an IT audit checklist follow? Pick a catalog written as things an organization does, so each item has a test. CIS Critical Security Controls v8.1 works well: 18 Controls and 153 Safeguards, with Implementation Group 1 as the minimum set. Map each row to ISO/IEC 27001:2022 Annex A and NIST CSF 2.0 so one test satisfies every framework you report against, as the checklist in this guide does.

How often should an IT risk assessment be done? ISO/IEC 27001:2022 clause 8.2 requires assessment at planned intervals or when significant changes are proposed or occur. NIST SP 800-30 Rev. 1 makes maintaining the assessment its fourth step, driven by monitoring risk factors. In practice: a full assessment each year, and a re-rating of affected scenarios after a new system, a significant published vulnerability, an incident or a failed audit test.

Does ISO/IEC 27001 require an internal audit before certification? Yes. Clause 9.2.1 requires internal audits at planned intervals to show that the management system conforms to the organization's own requirements and to the standard, and is effectively implemented and maintained. Clause 9.2.2 requires an audit program with frequency, methods, responsibilities, planning requirements and reporting, defined criteria and scope per audit, objective and impartial auditors, and results reported to management.

Is a SOC 2 report the same as an IT security audit? No. A SOC 2 examination is an attestation by a CPA firm against the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022), and reports to customers who rely on the service organization's controls. A Type 1 report covers design at a point in time; a Type 2 report covers design and operating effectiveness over a period. An internal IT audit is the rehearsal.

What counts as audit evidence for an IT control? ITAF standard 1205 requires sufficient and appropriate evidence. Sufficient means enough items across the period; appropriate means relevant to the control being tested and reliable in origin. System-generated exports, logs and reports outrank screenshots, which outrank statements. The evidence must show its date and the period it covers, and any sample must come from a population the auditor can prove is complete.

Sources

• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, National Institute of Standards and Technology, September 2012. Sections 2.3, 2.3.2 and 3 (Tasks 1-1 to 4-2); Tables D-2, F-2, G-2, G-3, G-4, G-5, H-3, I-2 and I-3. https://csrc.nist.gov/pubs/sp/800/30/r1/final (PDF: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf)
• NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, National Institute of Standards and Technology, 26 February 2024. Sections 2, 3.1 and 3.2; Appendix A (Functions, Categories and Subcategories GV.RM-05, GV.RM-06, GV.OV, ID.RA-01 to ID.RA-07, ID.IM); Appendix B (Tiers). https://doi.org/10.6028/NIST.CSWP.29 (PDF: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf). SmartSuite framework page: https://www.smartsuite.com/frameworks/nist-cybersecurity-framework-csf-v2-0
• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, third edition, October 2022. Clauses 6.1.2, 6.1.3, 8.2, 9.2.1, 9.2.2; Annex A Table A.1 (controls 5.1, 5.9, 5.12, 5.15, 5.18, 5.19, 5.24, 5.30, 5.35, 5.36, 6.3, 7.1, 8.2, 8.5, 8.7, 8.8, 8.9, 8.12, 8.13, 8.15, 8.16, 8.19, 8.20, 8.22, 8.23, 8.24, 8.25, 8.32). Catalog: https://www.iso.org/standard/27001 (catalog page returns 403 to automated fetches; URL is canonical). SmartSuite framework page: https://www.smartsuite.com/frameworks/iso-iec-27001-2022-information-security-management-system-isms
• ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks, fourth edition, October 2022. Foreword (main changes), Introduction, clause 1 Scope and table of contents (clauses 6 to 10, Annex A). Catalog: https://www.iso.org/standard/80585.html (403 to automated fetches). Preview with foreword and table of contents: https://cdn.standards.iteh.ai/samples/80585/7bca93ac16fd426a9bc717cadc9284d9/ISO-IEC-27005-2022.pdf. SmartSuite framework page: https://www.smartsuite.com/frameworks/iso-iec-27005-2022-information-security-risk-management
• ISACA, IT Audit Framework (ITAF): A Professional Practices Framework for IT Audit, 4th edition, standards and guidelines effective October 2020. Standards 1001 to 1008, 1201 to 1207, 1401 and 1402, as listed in ISACA Journal, "Standards, Guidelines, Tools and Techniques", volume 6, 2020: https://www.isaca.org/resources/isaca-journal/issues/2020/volume-6/standards-guidelines-tools-and-techniques. Press release, 22 October 2020: https://www.isaca.org/about-us/newsroom/press-releases/2020/isaca-updates-it-audit-framework-itaf
• ISACA, COBIT 2019: 40 governance and management objectives (https://www.isaca.org/resources/cobit); five domains as described by Mark T. Edmead, "Using COBIT 2019 to Plan and Execute an Organization Transformation Strategy", ISACA Industry News, 28 September 2020 (https://www.isaca.org/resources/news-and-trends/industry-news/2020/using-cobit-2019-to-plan-and-execute-an-organization-transformation-strategy); capability levels 0 to 5 per Kumaragunta Harisaiprasad, "COBIT 2019 and COBIT 5 Comparison", ISACA Industry News, 27 April 2020 (https://www.isaca.org/resources/news-and-trends/industry-news/2020/cobit-2019-and-cobit-5-comparison); objective and practice titles APO12.02, APO12.03, MEA01, MEA03, MEA04, MEA04.08, MEA04.09 as listed in UK Government, "Mapping the Cyber Governance Code of Practice to ISACA COBIT 2019", updated 11 August 2025 (https://www.gov.uk/government/publications/cyber-governance-mapping/mapping-cyber-governance-code-to-isaca-cobit-19). SmartSuite framework page: https://www.smartsuite.com/frameworks/cobit-2019-control-objectives-for-information-and-related-technologies
• Center for Internet Security, CIS Critical Security Controls Version 8.1, June 2024. Introduction (v8.1 changes, Implementation Groups), Control 1 to Control 18 overview pages (titles and Safeguard counts per IG; totals of 153 Safeguards, 56 in IG1 and 130 in IG2 are sums of the per-Control counts). Licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International. https://www.cisecurity.org/controls/v8-1 (guide PDF: https://www.cisecurity.org/insights/white-papers/cis-critical-security-controls-v8-1). SmartSuite framework page: https://www.smartsuite.com/frameworks/cis-critical-security-controls-v8-1
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022), Assurance Services Executive Committee. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022 (PDF behind a free AICPA account). AICPA guide, SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy, listed at https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2. SmartSuite framework page: https://www.smartsuite.com/frameworks/soc-2-system-and-organization-controls-for-trust-services-criteria

Related: GRC Foundation · What is cyber risk assessment? · What is compliance audit? · What is internal audit? · What is vulnerability management? · What is penetration testing? · Cyber Threat Management · Vulnerability Management for GRC · NIST SP 800-53 Rev. 5