Internal audit checklist: A step-by-step guide for GRC and security teams

A prospect's security team asks for proof that your access reviews ran every quarter this year. You have the reviews. You just can't find them fast enough, and now you're forwarding Slack threads at 9 p.m. while a six-figure deal waits.

That request, not the calendar, is increasingly what drives internal audits. Compliance has moved from an annual event to something a customer, regulator, or board member can ask you to prove tomorrow morning. This guide covers internal audits for cybersecurity compliance, specifically SOC 2, ISO 27001, NIST CSF, GDPR, and PCI DSS, not financial, corporate, or ESG audits, which serve different purposes. 

It walks through what a checklist actually is, the five-step process, how to organize evidence, and where automation genuinely helps.

‍What is an internal audit?

According to the Institute of Internal Auditors (IIA), an internal audit is "an independent, objective assurance and consulting activity designed to add value and improve an organization's operations."

It evaluates governance, risk, and controls to confirm that your security posture works the way your policies say it does, reviewing measures like access controls and incident response for both effectiveness and operational fit.

The distinction that matters most: an internal audit is risk-based, while an external or certification audit is scope-fixed. An internal auditor is part of the company and risk-assesses first, deciding where to look based on where the real exposure is. An external auditor arrives with a fixed framework and a fixed scope, testing only what the standard requires. That difference shapes everything down stream, what you test, how deep you go, and what you do with the findings.

For the full breakdown, see our guide on internal vs external audit differences.

Internal audits are typically conducted quarterly, annually, or ad hoc, depending on risk and regulation, with internal auditors reporting to the audit committee or senior leadership to preserve independence.

‍

‍

What is an internal audit checklist?

Take any framework requirement, for example "access must be reviewed quarterly," and you still need to decide who tests it, how, and what evidence proves it ran. That's what a checklist does: it turns the requirement into a testable step with a named owner.

It is not a policy document, which states intent, and it is not a risk register, which tracks exposure. A checklist maps each test step to a specific control, a named control owner, and a defined testing method, so an audit becomes a repeatable procedure rather than an improvised hunt.

The single most important structural decision is to organize the checklist by control, not by date or department. When an auditor asks for evidence on cryptography or access reviews, a control-organized checklist tells you exactly where that evidence lives. 

Organizing by date leaves you scavenging through folders while the auditor watches, which erodes confidence fast. Control-organized audit evidence management is what separates an audit-ready team from a scrambling one.

A useful internal audit checklist covers these components:

• Scope and objectives: which framework, which controls, and what the audit is trying to prove this cycle.

• Control mapping: each control tied to the framework requirement it satisfies, so overlapping frameworks reuse the same evidence.

• Testing method per control: inquiry, observation, inspection, reperformance, or analytical procedures, chosen to match the control.

• Control owner: the named person accountable for producing evidence, not "whoever has it."

• Evidence location: where the artifact lives, so it surfaces on request. See types of audit evidence for what auditors accept.

• Status and exceptions: pass, fail, or exception, with a date and an owner. An exception without a named owner and a date is just a documented problem.

What is the internal audit process?

The internal audit process is a structured, risk-based method for confirming your controls work and closing the gaps before an external auditor finds them. Guided by IIA standards, it runs in five steps.

Step 1: Pre-audit planning

Before any fieldwork begins, answer the three questions that the best auditors always ask. Was this process audited before? Were the prior findings actually remediated, or did they resurface? Have significant changes happened since, new systems, new data flows, a new business line, that shift where the risk sits? 

These questions keep the audit risk-based instead of rote. One more check that most teams skip: validate with the business leader that the audit is still relevant before you kick off, so you're not testing a process that no longer matters. This is also where you apply the audit risk model to decide which controls get the deepest testing.

Step 2: Auditor selection and briefing

Bring risk and process subject matter experts into the room before the planning meeting, not at the briefing stage. They know where the real exposure lives and will shape a sharper scope. The structural rule here is non-negotiable: the person who implemented a control cannot be the person who audits it. 

For lean teams, that means a cross-functional swap (someone who didn't build the control reviews it) or an external independent internal auditor for the first cycle. Independence isn't a nice-to-have; it's what makes the finding credible. Note that access reviews are a common area where implementer-auditor overlap creates blind spots.

Step 3: Audit execution

Execution is where you gather evidence. Two things are happening in parallel: choosing the right testing procedure for each control, and testing against a framework that tells you what you're actually looking for.

The five testing procedures each suit a different kind of control. Inquiry is questioning personnel about how a control operates. Observation is watching a process run in real time, such as an incident response drill. Inspection is reviewing documents and records, like a signed access review. Reperformance is re-executing the control yourself to confirm the outcome, such as retesting MFA enforcement. Analytical procedures compare data trends to surface anomalies.

The COSO 2013 framework tells you what you're testing for across five components:

• ‍Control environment (the tone and structure that makes controls possible)
• ‍Risk assessment (identifying what could go wrong)
• ‍Control activities (the specific policies and procedures that address those risks)
• Information and communication (ensuring the right people know what they need to know)
• Monitoring (checking that controls continue to work over time). 

You're testing for control, not just testing whether a control document exists. See types of audit evidence for how to match evidence to each method.

Step 4: Analysis and reporting

Expect a well-prepared team to invite deeper testing, not less. When auditors find clean, consistent results, they often expand the sample to confirm it holds. One Scrut audit saw the auditor keep increasing the endpoint monitoring sample precisely because the results kept coming back green. 

That's a sign of strength, not a problem. Your report should reflect the same rigor: findings need to be specific and quantified, not binary pass/fail flags. "Access review was not completed for two of four quarters, Q1 and Q3" tells leadership exactly what to fix. "Access review: fail" does not.

Step 5: Remediation and follow-up

Remediation closes the findings, but the step teams skip is the retrospective. Run a post-audit review after each cycle to identify what needs to change in your process, so the same gaps don't recur next year. Without it, you land in the same place every time. This is also where continuous compliance earns its keep: monitoring tools hold controls in a known state between audit cycles, which removes the last-minute remediation scramble entirely.

Which audit process is better?

Internal audits are the better default if you want oversight that actually improves your controls rather than just validates them. They're cheaper, run more often, and produce findings you can actually act on, not just a pass/fail verdict from an external auditor who leaves after fieldwork.

External audits remain essential for impartiality and regulatory mandates. SOX, for example, requires both external financial audits and internal control reporting. The two are complementary, not competing: internal audits provide proactive oversight, external audits provide independent validation. One thing worth knowing: the audit risk model, how the auditor decides where to push hardest, stays internal to the audit firm. You see the findings. You don't see the math behind them.

Currency matters here too. The 2024 IIA Global Internal Audit Standards (iia.org), effective January 9, 2025, introduced a new structure with sharper emphasis on emerging risk areas such as AI, cybersecurity, and third-party risk. A signal that internal audit scope is widening beyond traditional controls. This is also a reminder of why internal controls sit at the center of any credible program.

Minimum viable internal audit for lean teams (under 200 people)

Internal audit is not just for large organizations with dedicated GRC functions. For a company under 200 people, it's arguably more important. You have fewer controls, but you're building them fast, and quarterly checks catch drift before it compounds.

Who owns it when there's no GRC hire? The CTO or the CTO's team. Security and compliance controls speak the same language as your technology stack, and the CTO already understands the systems those controls run on. Handing the program to whoever has the most system context is the practical default until you hire a dedicated owner.

What cadence? Annual works for large organizations with fully implemented, stable controls. For companies under 200, quarterly or semi-quarterly is the right rhythm. Your control environment is still maturing, and more frequent checks catch problems while they're small.

What to audit every cycle? Four control categories carry the most weight:

1. Access controls. Every audit exception list has at least one access control finding. It's the most common gap, and the easiest to miss when you're the person who set up the permissions.‍
2. Cryptographic controls and key management: the backbone of the CIA triad.‍
3. Incident management: non-negotiable given how fast the threat landscape moves.‍
4. AI and data management controls: an emerging requirement that deserves a spot on the quarterly list now, not when your stack is fully AI-native.

Who runs it? Not the person who implemented the controls. Use a cross-functional swap, or bring in an external independent internal auditor for the first cycle. If you're a customer of a GRC program vendor, that vendor may offer this as a service.

A running start: If you already hold SOC 2, you're ahead. SOC 2 is such a comprehensive control set that roughly 40% of the internal audit work is effectively already done. Leverage those controls as your base rather than starting from scratch. Access reviews are usually the fastest of these to operationalize.

SOC 2 control review cadence by organization size

Framework-specific audit checklists

Different frameworks demand different checklists. Below are the cybersecurity frameworks first, followed by the quality management standards, which serve a different purpose.

ISO 27001

ISO/IEC 27001:2022 restructured the standard to 93 controls across four Annex A categories: organizational, people, physical, and technological (down from 114 in the 2013 version). Clause 9.2 mandates internal audits to verify ISMS effectiveness. 

Organize your evidence by control number, not by date. With 93 controls, control-wise filing is the only structure that scales. Test risk assessments, ISMS maintenance, and your risk treatment plan against the specific controls in scope. For the full walkthrough, see our ISO 27001 audit resource.

SOC 2

The Type I versus Type II distinction directly shapes what your internal audit checklist should test. Type I assesses control design at a point in time; Type II assesses operating effectiveness over a period, typically 6 to 12 months of observation. An internal audit ahead of a Type II must test whether controls actually operated over time, not just whether policies exist. Because the observation window is long, timing matters. 

Running your internal audit 2 to 3 months before fieldwork begins is the practical window to catch and fix gaps while there's still time. In Scrut's own SOC 2 audit, EY went deep on BCP testing and access review depth, expanding both when the initial evidence held up. That's exactly what a rigorous SOC 2 auditor does.

See our SOC 2 audit best practices for the operating-effectiveness detail.

HIPAA

Before the checklist: HHS and its Office for Civil Rights do not issue HIPAA certifications. If your policies use "HIPAA certified" language anywhere, remove it now. HIPAA is a law enforced through investigation, not a credential you earn.

• Controls: administrative, technical, and physical safeguards.

• Processes: risk analysis and breach notification readiness.

• Documentation: security policies and risk assessment reports.

• Audit requirement: confirm Privacy and Security Rule adherence.

Your internal audit should test breach notification readiness specifically, not just whether the safeguard controls exist, but whether the team could actually execute a compliant notification on the clock. For the broader program, see HIPAA compliance.

PCI DSS

• Controls: cardholder data environment scoping, network segmentation, MFA.

• Processes: quarterly vulnerability scans, annual penetration testing.

• Documentation: ROC or SAQ, network diagrams.

• Audit requirement: Level 1 merchants and service providers need a Qualified Security Assessor (QSA); smaller merchants use SAQ tiers.

When selecting a QSA, verify the firm's license and regional approval on the PCI council website. Not all firms are approved for all regions, and the council is tightening QA requirements toward a model where the assessor and the QA reviewer are different people. Scoping the cardholder data environment correctly is where most PCI failures begin. Our PCI DSS compliance guide covers the boundary decisions in detail.

Quality management framework checklists (ISO 9001:2015 and ISO 13485)

These are quality management standards, not cybersecurity compliance frameworks, but they appear here for completeness.

ISO 9001:2015 covers leadership engagement and operational controls, with Clause 9.2 requiring internal audits of quality processes. Documentation centers on quality policies and process records.

ISO 13485 covers management responsibility and product realization controls for medical devices, with Clause 8.2.4 mandating internal audits. Documentation centers on QMS policies and device compliance records. See our ISO 13485 overview for the medical-device specifics.

Comparative breakdown of key framework requirements

Audit evidence management: How to organize evidence so auditors can find it

Ask any GRC manager what kills audit prep time and the answer is almost always the same: not collecting evidence, but finding it.

Organize by control, not by date or department. When an auditor requests evidence for a specific control, a control-organized system surfaces it in seconds. With 93 controls in ISO 27001, control-wise evidence collection is the priority for anyone getting into audits. A universal search on the control name should land you on the artifact.

The four failure patterns that generate exceptions:

• Date-named files in personal drives. An evidence file called `access_review_July6.xlsx` sitting in someone's personal drive with no control mapping is invisible when the auditor asks for it three months later.

• Approvals over Slack. A thumbs-up emoji on a Slack message is not acceptable approval to an auditor. Approvals need to be captured in a system with a timestamp and a named approver.

• Missing sign-off emails on routine reviews. A missing sign-off email on a quarterly firewall review was enough to generate an exception in Scrut's own EY audit, even though the review itself was done on time. Take a sign-off from upper management on every recurring review, however small it seems.

• Departed-employee access not tracked. An active Google Drive account for a departed employee surfaces as an exception the moment the auditor samples that person. Offboarding has to close every account, not just the obvious ones.

Coordinate multi-stakeholder evidence. When two teams own inputs to the same control, designate one control owner to consolidate both. Asset inventory is the canonical cross-functional example: HR and IT both hold pieces of the same picture, and someone has to bring them together before the auditor arrives.

Cover the full observation period. For SOC 2 Type II (minimum six months) and ISO 27001 (annual), auditors sample from across the entire period, not just the most recent quarter. Evidence has to span the whole window.

The cost of poor organization is not just lost time. An auditor watching a GRC manager scramble to find evidence during fieldwork reads it as a control deficiency signal. Every inconsistency raises their assessed risk of material misstatement, which means deeper testing and more evidence requests. 

See audit evidence, evidence collection automation, and user access review for the operational detail.

For the documentation discipline behind it, see our guide on audit documentation.

Once your evidence is organized, the next question is who should be reviewing it, and whether that person is the right one.

How to select an internal auditor (and when to switch)

Four evaluation criteria apply across frameworks, but one structural rule comes first regardless of team size: the person who implemented a control cannot audit it. That's not a preference. It's what makes the finding credible.

Evaluating an external auditor:

• Accreditation and peer review. For SOC 2, verify the firm's AICPA peer review enrollment and pass rating on the AICPA website. For ISO, confirm the certification body is accredited by a member of the International Accreditation Forum (IAF) at iaf.nu. For PCI, verify the QSA license and regional approval on the PCI council site.

• Technical credentials of the individual auditors. Look for CISA, CISSP, or equivalent. A CPA alone auditing cloud-native infrastructure isn't enough. Ask specifically about the auditors' technology background.

• Separate audit and QA teams. The assessor and the QA reviewer should be different people. Big 4 firms have long operated this way, and PCI is moving toward requiring it. Ask directly about the QA process.

• References from organizations that look like yours. Same industry, similar size, cloud-native stack. "We've audited 20 SaaS companies" is not the same as "we've audited 20 SaaS companies at Series B selling into financial services."

When to switch auditors? Industry best practice, and some regulatory regimes, such as the RBI for regulated entities, is to change firms after two consecutive audits. Staying too long dulls the audit: the auditor knows where the potholes are and may drive around them. 

And if the only reason your compliance team wants to keep the same auditor is that they know they can get away with existing gaps, that's the clearest possible signal it's time to switch. Applying the audit risk model freshly with a new firm often surfaces things the incumbent stopped looking for.

Boutique vs. Big 4? A SOC 2 report is a SOC 2 report. The AICPA standard is identical regardless of which licensed firm produces it. The real difference is in how hard they push. Big 4 firms sample more, test deeper, and are more likely to find the exception you hoped they wouldn't. As you mature and sell into financial services or enterprise buyers who scrutinize audit firm credibility, Big 4 becomes the more defensible choice.

Don't confuse readiness assessments with consulting. A readiness assessment uses the same control checklist as the final audit and produces findings. It does not prescribe how to fix them. If a firm is telling you how to remediate as part of a "free" readiness assessment, that's a sales call, not an assessment. See our SOC 2 readiness assessment guide and our breakdown of boutique vs Big 4 auditors.

Common mistakes to avoid when using audit checklists

1. Overlooking stakeholder input. Failing to engage the audit committee or management when defining scope leads to misaligned priorities. If leadership only shows up at kickoff and disappears, the audit tests the wrong things. Bring the business leaders in early enough to shape what actually gets tested.

2. Treating checklists as static. A checklist that isn't tailored to your specific controls misses real risk. Copying a generic ISO 27001 or SOC 2 checklist without mapping it to your environment produces an audit that passes on paper while leaving actual gaps untested.

3. Ignoring documentation. Incomplete records undermine otherwise sound work. Auditors treat a gap in the paper trail as a gap in the control, even when the underlying work was done correctly and on time. The firewall sign-off example from the evidence section is not an edge case. It's the rule.

4. Skipping follow-up. Identifying a non-compliant control and never remediating it turns the audit into documentation of a known problem. Track every finding to closure with an owner and a date, or the same gap resurfaces next cycle.

5. Testing policies, not controls. A well-written policy with a control marked "implemented" is not the same as a control that operates effectively. Auditors will dig past the policy into the system. Teams that can produce polished procedures often can't answer how those procedures actually run in production. Test the implementation, not the document.

6. Assuming a clean readiness score means audit-ready. A green readiness score is a starting point, not a finish line. A human auditor reading your policies for the first time will find things the platform cannot, especially if your business model has changed since you last updated them. See our guides on compliance automation and common compliance mistakes.

Making internal audits smarter with automation

As organizations scale, audits get harder in every dimension at once: more controls, more evidence, more stakeholders, more frameworks, and less time to reconcile them. Managing that manually, without a single system of record, is where drift compounds and audit exceptions multiply.

Automation handles the grunt work, real-time evidence collection and control monitoring, but it does not replace human judgment. Assessing whether a policy is correctly drafted for your environment, determining control design effectiveness, and signing a management assertion all remain human acts. The practical division of labor is clean: automation does 100% sampling on technical checks like endpoint or access review coverage, while a human auditor still reads the policies and makes the judgment calls.

Automation flips the view. Instead of confirming that everything is fine, one control at a time, you surface only what's failing, which is far more efficient at scale. The teams that struggle check the tool once after certification, then get a call from the auditor two weeks before the surveillance window and realize they're a hundred controls behind. The fix is boring: check weekly, fix drift as it appears.

This is where a platform earns its place. Scrut connects to your cloud, HR, and IT systems to pull real-time evidence across controls, maps existing controls to multiple frameworks so you don't duplicate work, keeps version-controlled audit logs, and assigns tasks to the right owners.

The goal isn't a quarterly scramble. It's a strategic rhythm built into how your team works every day. For the broader picture, see GRC automation, continuous compliance, automated evidence collection, the continuous audit era, and the human element in compliance.