Security Audit Procedures: A Step-by-Step Checklist for IT Teams

Updated: October 2026

Someone asks for a security audit, and the first week disappears into arguing about what it covers. A good audit is a set of repeatable steps: agree the scope, pick the yardstick, collect evidence, test, rate what you find and follow it to closure. This guide walks through security audit procedures step by step, with a checklist an IT team can run internally or hand to an outside auditor.

TL;DR

• A security audit checks your controls against a standard and proves it with evidence. It's broader than a vulnerability scan and less aggressive than a penetration test.
• Decide three things before fieldwork: the scope, the framework you'll audit against (NIST CSF 2.0, CIS Controls v8.1 or ISO/IEC 27001:2022) and who signs off on the findings.
• Evidence beats answers. Screenshots, exports and samples settle what interviews only claim.
• The technical checks that find the most problems are the dull ones: admin group membership, service account passwords, firewall rules nobody owns, MFA gaps and untested restores.
• Rate every finding with the same method, give each one an owner and a date, and re-test before you close it.
• Run a full audit once a year, access reviews every quarter and vulnerability scans every month.

What a Security Audit Is, and What It Isn't

A security audit compares how your environment works today against a defined standard. The standard can be a framework, a regulation, a contract or your own security policy. The output is a list of findings, each backed by evidence.

Three other activities get called an audit, and they answer different questions.

A vulnerability scan asks which known weaknesses exist on the systems a scanner can reach. It's automated and runs often. A penetration test asks what an attacker could do with those weaknesses, and a tester proves it by exploiting them. A risk assessment asks which threats matter most to the business and what they would cost.

An audit uses all three as inputs. It then goes further and checks whether the processes around them work. A scanner can tell you a server is missing a patch. An audit asks why the patch process missed it, and whether it's missing on forty other servers too.

Types of Security Audit

Audits split along three lines: who runs them, why they run, and what they test.

Internal audits are the cheapest way to get ready for an external one. The same procedures apply to both. The difference is independence: an outside auditor's signature carries weight with customers, insurers and regulators that your own report doesn't.

If you're auditing a vendor rather than being audited, the same steps work. Our guide to vendor risk management covers the questionnaire side of second-party audits.

Step 1: Set the Scope and the Objective

Scope decides whether the audit finishes. Write it down in one page before anything else happens.

Start with the objective in one sentence. "Confirm we meet CIS Controls IG1 before the insurance renewal" is an objective. "Check our security" isn't.

Then list what's in and what's out. Name the sites, the business units, the systems and the cloud tenants. Name the period under review, since a control that worked last week may not have worked in March. Name the out-of-scope items too, with a reason, so nobody assumes they were checked.

Last, agree who owns the result. Someone with authority has to accept the scope at the start and the findings at the end. On a small team that's usually the IT lead and one business owner. Without that person, findings turn into a debate about whether they count.

Step 2: Pick the Framework You'll Audit Against

An audit needs a yardstick, and a framework gives you one that someone else already argued over. Three cover almost every small and mid-sized team.

NIST CSF 2.0, released on 26 February 2024, organizes security into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is new in 2.0. It's broad and outcome-based, which makes it good for a first audit and for reporting to leadership. The NIST CSF 2.0 release describes each function.

CIS Controls v8.1 is prescriptive. It lists 18 controls and 153 safeguards, grouped into three implementation groups. CIS describes IG1 as "essential cyber hygiene", the set every organization should start with. For a technical audit on a small budget, IG1 is the most practical checklist available.

ISO/IEC 27001:2022 is a certifiable management system standard. Its Annex A has 93 controls in four themes: organizational, people, physical and technological. Organizations certified to the 2013 version had until 31 October 2025 to move to the 2022 version. Pick it when a customer or a tender asks for the certificate.

You don't need all three. A common pattern is CIS IG1 for the technical checks and CSF 2.0 for the report to leadership. Our cybersecurity frameworks list compares the wider field, including NIST 800-171, SOC 2 and HIPAA.

Step 3: Plan the Fieldwork

Fieldwork is the part where evidence gets collected and tested. Planning it well saves the most time.

Build a request list first. Auditors call it a PBC list, "provided by client". It names every document, export and screenshot you'll need, who provides it and by when. Send it two weeks before fieldwork starts. The items that arrive late are the ones that reveal gaps.

Agree the rules of engagement for technical testing. Write down which systems can be scanned, from where, when, and who to call if a scan knocks something over. Get that approval in writing from the system owner.

Decide how evidence moves. Use one shared folder with restricted access, not email attachments. And settle what the auditor will never receive. A legitimate audit reviews settings, logs and account lists. It never needs live passwords.

That last point trips people up. This r/sysadmin thread describes a request to hand over a list of credentials "to show security compliance". Treat any request like that as a red flag, whoever it claims to come from, and verify it through a contact you already know.

Step 4: Collect Evidence

Evidence is what separates an audit from a conversation. Every conclusion in the report should point to something you can show.

Good evidence has three qualities. It's relevant to the control being tested. It's reliable, meaning it came from the system rather than from someone's memory. And it's sufficient, meaning there's enough of it to support the conclusion.

Four kinds cover most controls:

• Documents: policies, procedures, network diagrams, asset registers, contracts.
• System exports: user lists, group memberships, firewall rule sets, patch reports, backup job logs. Exports straight from the system are stronger than reports someone typed up.
• Screenshots: configuration pages, with the date, time and system name visible in the frame.
• Samples: a set of real records tested against the control, such as ten leavers from the last quarter checked for disabled accounts.

Sampling keeps the work finite. You don't check every leaver. You pick a sample across the period, test each one, and extrapolate. If one in ten fails, the control fails, and the finding says so with the sample attached.

Log every item in an evidence register: what it is, which control it supports, who provided it and when. Six months later, when someone asks how you reached a finding, the register answers.

Collecting the same export from forty machines by hand is where audits stall. In OpenFrame, you can run the collection script across a client's devices and pull the output into one place.

Step 5: Run Interviews and Walkthroughs

Interviews tell you how a process is supposed to work. Walkthroughs show you how it works.

Interview the people who run the controls, not only the people who own them. The service desk lead knows how account requests get approved. The person who restores files knows whether backups get tested. Ask open questions: "Walk me through the last time a user left", not "Do you disable accounts for leavers?"

Then ask them to show you. Pick one real case and follow it through the systems. An offboarding walkthrough might take you from the HR ticket, to the directory, to the email tenant, to the VPN, to the password manager. Every handover in that chain is a place where a step gets skipped.

Write down the gap between the stated process and the observed one. That gap is often the most useful finding in the report, because it explains why the technical problems exist.

Step 6: Test the Technical Controls

Technical testing checks the configuration directly. NIST's guide on the subject, SP 800-115, groups the methods into reviewing documents and settings, finding targets, and validating vulnerabilities. For an internal audit, six areas carry most of the risk.

Privileged access. List every member of the admin groups and ask why each one is there. On Active Directory, start with:

powershell
Get-ADGroupMember "Domain Admins" -Recursive | Select-Object Name, SamAccountName
Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonDate, PasswordLastSet |
  Where-Object { $_.LastLogonDate -lt (Get-Date).AddDays(-90) } |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet

The second command finds enabled accounts nobody has used in 90 days. Cross-check that list against HR's leavers. Check service accounts separately: their passwords rarely change, and they often hold far more rights than the job needs. Our guide to role-based access control covers how to redesign those rights once you've found them.

MFA coverage. Confirm MFA on email, VPN, remote access tools and every cloud admin portal. Look for the exceptions, since each one is a bypass.

Vulnerabilities and patching. Run an authenticated scan, which logs in to read installed software, not just an external one. Compare the results with your patch reports. According to Verizon's 2026 Data Breach Investigations Report, 31% of breaches now start with an exploited software vulnerability, ahead of stolen passwords. Prioritize internet-facing systems first. Our comparison of vulnerability management software covers tools for this step.

Secure configuration. Compare servers and endpoints with a hardening baseline such as the CIS Benchmarks. Check that local admin rights are removed from standard users and that endpoint protection is running on every device, not just most of them.

Network and firewall rules. Export the rule set. Flag any-to-any rules, rules nobody can explain and rules for systems that no longer exist. Check egress filtering too, since plenty of networks restrict inbound traffic and let everything out.

Logging and backup. Confirm the logs you'd need in an incident exist and are kept long enough. Then restore something. A backup job that reports success proves the job ran, not that the data comes back.

This checklist from r/sysadmin, posted by someone with more than ten years in network security, covers the same ground from a practitioner's side: firewall rules, admin accounts, service accounts and the leavers nobody disabled.

An internal audit usually stops short of exploiting what it finds. When you need proof of what an attacker could reach, bring in a tester. Our guide to network penetration testing explains what that engagement covers.

Step 7: Rate the Findings

A list of fifty findings with no ranking gets ignored. Rate every finding the same way so the team knows where to start.

Score each one on likelihood and impact. Likelihood asks how easy the weakness is to exploit and how exposed the system is. Impact asks what happens to the business if it's exploited: data lost, systems down, money gone, a regulator involved. Combine the two into four levels: critical, high, medium and low.

Write each finding in a fixed structure, so anyone can read it without the auditor in the room:

Agree remediation targets by level before the report goes out. An illustrative set: critical in 7 days, high in 30, medium in 90, low at the next review. Your own targets should match your risk appetite and any contract or insurance terms.

Note what works too. A report that only lists failures reads as an attack, and the team defends instead of fixing. Controls that passed belong in the report, briefly.

Step 8: Write the Report

The report has two readers. Leadership reads the first page. The technical team reads the rest.

Open with a one-page summary: the objective, the scope, the overall result, the count of findings by level and the three findings that matter most. Leadership should be able to decide on budget and priorities from that page alone.

Then cover the method: the framework, the period, the sample sizes and anything that limited the work, such as a system you couldn't access. Put the findings next, sorted by level, each in the fixed structure above. End with the evidence register as an appendix.

Share a draft with the control owners before the final version. They'll correct factual errors and add management responses: whether they agree, what they'll do and by when. A finding with an agreed response gets fixed. A finding that arrives as a surprise gets argued.

The Institute of Internal Auditors' short introduction covers how auditors approach cybersecurity, and it's a useful primer for anyone running their first internal audit:

Step 9: Track Remediation and Re-Test

The audit ends when the findings close, not when the report ships.

Put every finding in a tracker with an owner, a due date and a status. The ticketing system you already use works fine. What matters is that someone reviews the list on a fixed schedule, usually every two weeks, and chases the overdue items.

Some findings won't get fixed. The cost is too high, or the system retires next year. Handle those with a formal risk acceptance: the business owner signs that they understand the risk and accept it until a named date. Accepted risk is a decision. An open finding nobody mentions is an oversight.

Re-test before closing. Ask for fresh evidence, not a note saying "done". If the finding was four enabled leaver accounts, the closing evidence is a new sample showing zero.

How Often to Run a Security Audit

A full audit once a year is the usual baseline. Some controls drift faster than that, so check them in between.

Compliance adds its own clock. A SOC 2 Type II report covers controls over a period, typically three to twelve months, so the evidence has to exist across that whole window. Our guide to SOC 2 compliance covers what that means in practice. Regulations can also set the cadence directly: the FTC Safeguards Rule, for one, requires regular testing of safeguards and a written report to the board.

For planning the year of audits around those clocks, SANS Institute has a webcast on building a 2026 cybersecurity audit plan:

The Security Audit Checklist

Use this as the working list for an internal audit. Each row names the area, what to check and the evidence to keep.

If you work to a specific regulation, map this list against it. Our FTC Safeguards Rule checklist shows what that mapping looks like for one rule.

Mistakes That Make an Audit Useless

The same few mistakes turn a week of work into a report nobody acts on:

• No agreed scope. The findings get dismissed as out of scope.
• Answers accepted as evidence. "Yes, we do that" isn't proof. A sample is.
• Findings without owners. Everyone agrees, nobody fixes.
• Closing on a promise. Without a re-test, "fixed" means "someone said so".
• Auditing your own work. The person who built the firewall shouldn't be the one who reviews its rules.

That last one is hard on a small team. If there's no one independent inside, swap audit areas between two people, or bring in an outside auditor for the areas you built yourself.

Run the Audit, Then Close It

Security audit procedures come down to nine steps: scope, framework, plan, evidence, interviews, technical tests, rating, reporting and re-testing. The checklist above covers the controls that fail most often, and the annual cadence keeps them from drifting back.

Start with CIS IG1 if this is your first audit, and keep the scope small enough to finish. For the governance side of the same work, read our guide to building an IT governance framework around NIST CSF 2.0.