November 4, 2026
Updated: November 4, 2026
Audit types, a seven-step process, a 13-domain checklist, the evidence auditors accept and where a penetration test fits.
Mohammed Khalil
An IT security audit is a formal, evidence-based review that checks whether your security controls are designed and working as a chosen standard requires. Common standards include ISO/IEC 27001, NIST CSF 2.0, the CIS Controls and SOC 2. An auditor defines the scope, collects documents and system records, interviews control owners, tests samples and reports each gap as a finding against a specific requirement. A penetration test answers a different question: can an attacker actually exploit your systems? Mature programs use the pentest as one piece of technical evidence inside the audit.
| Question | Short answer |
|---|---|
| What does it check? | Whether security controls exist, are designed well and operate as required |
| Against what? | Defined criteria: ISO/IEC 27001:2022, NIST CSF 2.0, CIS Controls v8.1, SOC 2, PCI DSS, HIPAA or your own policy |
| How? | Document review, interviews, observation, sampling and technical testing of controls |
| What evidence? | Policies, asset inventories, access reviews, change tickets, logs, scan and pentest reports, backup tests, incident records |
| What comes out? | Findings rated against criteria, an opinion or certification decision (external audits) and a remediation plan |
| Who performs it? | Internal audit (first party), a customer (second party) or an independent body such as a certification body or CPA firm (third party) |
| How often? | At planned intervals, usually yearly, and after major change; some frameworks set their own cycle |
NIST's glossary, quoting the Committee on National Security Systems, defines a security audit as an "independent review and examination of records and activities" that assesses whether system controls are adequate, checks compliance with established policies and procedures, and recommends changes (NIST CSRC glossary). The same entry adds a warning worth repeating: audit, inspection and assessment are sometimes used as synonyms, but they are not interchangeable.
Three things make an audit an audit:
People also use "IT security audit," "cybersecurity audit" and "information security audit" for the same work. In practice the scope differs slightly. An information security audit can include paper records and physical handling of information. A cybersecurity audit leans toward digital systems. An IT audit in the classic sense (for example, IT general controls in a financial audit) also covers areas such as operations and change management for financial reporting. This guide uses "IT security audit" for the security-focused review of people, process and technology controls against a framework.
If you are not sure you need an audit at all, read our guide to security assessment types. Assessments find and rank weaknesses so you can improve. Audits check conformance to criteria and produce a formal result. Many organizations run an assessment first so the audit is not the first time anyone looks.
Audits are usually described along two axes: who performs them and what they examine.
| Type | Performed by | Typical trigger | Output |
|---|---|---|---|
| Internal (first-party) audit | Your internal audit, GRC or security assurance team, or a contracted auditor acting for you | ISO/IEC 27001 clause 9.2, board oversight, readiness before an external audit | Internal audit report and corrective actions |
| Second-party audit | A customer, partner or parent company auditing you as a supplier | Contract clause, vendor risk program | Supplier assessment result, contractual follow-up |
| External (third-party) audit | An independent body: accredited ISO certification body, CPA firm (SOC 2), Qualified Security Assessor (PCI DSS), or government assessor | Certification, attestation, regulatory or card-brand requirement | Certificate, attestation report or formal report on compliance |
Internal audits are cheaper and can run more often, but they rarely satisfy a customer who asks for independent assurance. External audits carry weight with customers and regulators because the auditor has no stake in the result.
Most real audits mix these. A SOC 2 Type 2 examination, for example, is a compliance audit that relies heavily on technical and process testing.
Pick the framework your customers, regulators or board will accept, then add depth where it helps. The table summarizes the frameworks US organizations use most often for security audits.
| Framework | Owner and current version | What it is | Certifiable? | Built-in audit element |
|---|---|---|---|---|
| ISO/IEC 27001 | ISO/IEC; 2022 edition (Amendment 1 in 2024 added climate-change wording to clauses 4.1 and 4.2) | Requirements for an information security management system (ISMS), with 93 Annex A controls in four themes | Yes, by accredited certification bodies | Clause 9.2 requires internal audits at planned intervals; Annex A 5.35 requires independent review of information security |
| NIST CSF 2.0 | NIST; CSWP 29, February 26, 2024 | Outcome-based framework with six Functions: Govern, Identify, Protect, Detect, Respond, Recover | No; voluntary | Organizations audit against a target profile they define |
| CIS Controls | Center for Internet Security; v8.1, June 2024 | 18 prioritized Controls with 153 Safeguards; Implementation Group 1 covers 56 essential Safeguards | No; used as a technical benchmark | Each Safeguard is specific enough to test directly |
| SOC 2 | AICPA; 2017 Trust Services Criteria with revised points of focus (2022) | Examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy | Attestation report by a CPA firm, not a certificate | Type 1 covers design as of a date; Type 2 adds operating effectiveness over a period |
| PCI DSS | PCI Security Standards Council; v4.0.1 | Technical and operational requirements for environments that store, process or transmit payment account data | Validated by a QSA report or self-assessment questionnaire | Requirement 11 covers vulnerability scanning and penetration testing |
| HIPAA Security Rule | HHS; 45 CFR Part 164, Subpart C | Safeguards for electronic protected health information (ePHI) | No certification | 45 CFR 164.308(a)(8) requires periodic technical and nontechnical evaluation |
A few notes on using these sources correctly:
If you sell to enterprises, SOC 2 or ISO/IEC 27001 usually decides the scope. If you have no external requirement yet, the CIS Controls or a CSF 2.0 profile give you a defensible, testable baseline.
The steps below follow the planning, fieldwork and reporting structure used across ISO audit guidance (ISO 19011) and NIST's control assessment procedures. Timelines vary with scope. A focused internal audit of one system can take a few weeks, while a first SOC 2 Type 2 runs over an observation period that the CPA firm agrees with you.
Write down why the audit is happening (certification, customer request, regulatory evaluation, internal assurance), which criteria apply and what is in scope: business units, locations, cloud accounts, applications, third parties and the period under review. Agree on what is out of scope in writing. Most audit disputes start with a vague scope.
The auditor builds an audit plan and sends an evidence request list, often called a PBC ("prepared by client") list. Assign one owner per request and a due date. Ask early which evidence must be system-generated and which populations the auditor will sample from, such as all new hires in the period or all production changes.
The auditor reads policies, standards, procedures, the risk assessment, the asset inventory, network and data-flow diagrams and, for ISO/IEC 27001, the Statement of Applicability. The question at this stage is design: if people followed these documents, would the requirement be met?
Control owners explain how each control works in practice. Walkthroughs follow one real transaction through a process, for example one access request from ticket to approval to provisioning. Interviews often reveal the gap between the written policy and the actual practice.
NIST SP 800-53A describes three assessment methods: examine (review documents, records and configurations), interview (discuss with individuals or groups) and test (exercise mechanisms or activities under specified conditions and compare actual with expected behavior) (NIST SP 800-53A Rev. 5). In an audit that means:
Each finding should state the condition (what was found), the criterion (which requirement it breaks), the cause, the effect or risk and a recommendation. ISO certification audits grade nonconformities as major or minor. SOC 2 reports list exceptions found in testing. Internal audits usually rate findings by risk so owners know what to fix first.
The report goes to management with agreed corrective actions, owners and dates. Follow-up testing confirms the fixes worked. For technical findings that means a retest, not just a closed ticket. Feed the results into the next audit plan.
Use this checklist to prepare for an audit or to run an internal one. Each domain lists what to verify, the evidence an auditor will ask for and where the domain maps in NIST CSF 2.0, CIS Controls v8.1 and ISO/IEC 27001:2022 Annex A. The mappings are a starting point. Confirm them against your framework's official mapping before you rely on them.
For a deeper vendor program, see our guide to third-party risk management.
Auditors judge evidence by quality, not volume. The table shows what typically gets rejected and how to fix it before fieldwork.
| Evidence type | What auditors accept | What gets rejected | How to prepare |
|---|---|---|---|
| Policies and procedures | Approved, dated, version-controlled documents | Drafts, undated files, policies that contradict practice | Keep a policy register with owner, approval and review dates |
| Populations | Complete, system-generated lists for the full period | Hand-built spreadsheets, partial periods | Export directly from the source system and record the query used |
| Access reviews | Signed or ticketed reviews showing decisions and follow-up removals | A review with no actions, or no proof it happened | Store reviewer, date, decisions and removal tickets together |
| Change records | Tickets showing approval before deployment and testing | Approvals dated after the change | Enforce approval gates in tooling |
| Logs and alerts | Exports showing retention, alerts and triage actions | Screenshots of dashboards with no dates | Include timestamps and the reviewer's action |
| Vulnerability scans | Authenticated scans covering in-scope assets, with remediation tracking | Unauthenticated scans, missing assets, no follow-up | Reconcile scan coverage against the asset inventory |
| Penetration test | Recent report with scope, methodology, findings, severity and retest results | Out-of-date report, scope that misses in-scope systems, no retest | Align the pentest scope with the audit scope and schedule the retest |
| Backup and recovery | Restore-test records with date, system and outcome | Backup job success reports only | Run and document restore tests |
| Incident response | Exercise report and real incident timelines | Plan document only | Run a tabletop and record lessons learned |
Two rules prevent most evidence problems. First, the evidence must cover the whole audit period, which matters most for SOC 2 Type 2 and other period-based audits. Second, the evidence must show the control operating, not just existing. A configured setting proves design. A sample of real tickets, alerts and reviews proves operation.
The two answer different questions, and confusing them is the most common reason audit scopes go wrong.
| Dimension | IT security audit | Penetration test |
|---|---|---|
| Core question | Are controls designed and operating as the criteria require? | Can an attacker exploit weaknesses, and how far can they get? |
| Basis | A framework, regulation or policy | Attack techniques and a test methodology (for example, NIST SP 800-115) |
| Methods | Document review, interviews, sampling, configuration inspection | Reconnaissance, manual exploitation, privilege escalation, chaining weaknesses |
| Evidence produced | Findings against requirements, an opinion or certificate | Proof of exploitable vulnerabilities with reproduction steps and severity |
| Coverage | Broad: people, process and technology across the organization | Deep: specific applications, networks or cloud environments |
| Typical result | Conformance status and corrective actions | Exploitable findings, attack paths and remediation guidance |
| Who performs it | Internal audit, certification body, CPA firm, QSA | Qualified testers, internal or external |
A clean audit does not prove you cannot be breached, and a clean pentest does not prove you are compliant. An audit can confirm that a vulnerability management process exists and runs on schedule, while a pentest shows whether that process actually prevents exploitable weaknesses. For the difference between scanning and testing, see vulnerability assessment vs. penetration testing.
Penetration testing shows up in audits as evidence for specific requirements:
Our guide to penetration testing for compliance maps which frameworks require testing and how often.
Running the pentest after fieldwork starts leaves open findings in front of the auditor with no time to fix them. Running it 12 months before means it may fall outside the period or no longer match the environment.
Use an internal audit when you need regular assurance, are preparing for certification or must meet ISO/IEC 27001 clause 9.2. Use an external audit when a customer, regulator or card brand requires independent assurance, or when you need a certificate or attestation report to win business. Most organizations need both: internal audits throughout the year and an external audit on the framework's cycle.
There is no single legal interval for every organization. Base the cadence on the framework and on risk:
A practical default is a full internal audit once a year, focused audits of high-risk areas between cycles and a targeted review after major changes, such as a cloud migration, an acquisition or a new product that handles sensitive data.
DeepStrike is not an audit firm. We do not issue SOC 2 opinions, ISO certificates or PCI reports on compliance. We supply the technical testing evidence that auditors ask for. Our penetration testing services are manual and human-led across web and mobile applications, APIs, cloud and infrastructure. Reports are prepared to support compliance requirements such as SOC 2 Type II, ISO 27001, HITRUST, HIPAA and PCI DSS, with reproduction steps, root causes, remediation guidance and an attestation letter. Remediation retesting lets you show the auditor closed findings, not just open ones.
An IT audit is broader. It can cover IT general controls for financial reporting, operations, change management and project governance. An IT security audit focuses on whether security controls protect the confidentiality, integrity and availability of systems and data against a security framework. In practice the two overlap in areas such as access management and change control.
No. An audit checks whether controls are designed and operating as a framework requires, using documents, interviews and sampling. A penetration test checks whether an attacker can exploit your systems. Audits often use a pentest report as evidence for vulnerability management and security testing controls.
An audit measures controls against defined criteria and produces a formal result, such as findings against requirements, an opinion or a certification decision. An assessment evaluates your posture to find and prioritize weaknesses, with no pass or fail. Our guide to security assessment services compares the main assessment types.
It depends on scope and framework. A focused internal audit of one system may take a few weeks from planning to report. External audits take longer: SOC 2 Type 2 reports cover an observation period agreed with the CPA firm, and ISO/IEC 27001 certification involves separate audit stages. Preparation time is often longer than fieldwork.
Anyone independent of the controls being audited can run an internal audit, including an internal audit team or a contracted auditor. External audits require specific bodies: SOC 2 reports are issued by licensed CPA firms, ISO/IEC 27001 certificates by certification bodies, and PCI DSS reports on compliance by Qualified Security Assessors.
Scope, criteria and period; the methods used; an executive summary; each finding with condition, criterion, cause, risk and recommendation; a risk rating; management responses with owners and dates; and, for external audits, the opinion or certification decision.
It depends on the audit. ISO/IEC 27001 certification can be withheld until major nonconformities are corrected. A SOC 2 report can include exceptions or a modified opinion. Internal audits do not pass or fail, but unresolved high-risk findings are escalated to management.
An IT security audit is only as good as its criteria, scope and evidence. Pick the framework your customers and regulators accept, use the checklist to find gaps, collect system-generated evidence that covers the whole period, and test the technical controls before the auditor does. If your audit needs independent technical evidence, talk to DeepStrike about penetration testing scoped to your audit, with a retest before fieldwork.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
