A cybersecurity audit is an evidence-based check of whether an organization's security controls are designed properly and work in practice, measured against a defined set of criteria. The criteria can be a framework, a regulation or a customer contract, and the choice shapes everything else: scope, evidence, auditor and output.
For a scaling software company, the useful question is usually which audit a specific trigger demands, such as a customer questionnaire, a card-data requirement or a regulated buyer, and how much of the work can be done in-house.
What is a cybersecurity audit and why does it matter?
A cybersecurity audit is a systematic, evidence-based check of an organization's security controls, policies and configurations against a defined standard, ending in documented findings. The standard can be NIST Cybersecurity Framework (CSF) 2.0, ISO/IEC 27001:2022, or a customer contract.
An audit separates control design from operating effectiveness, catching the access review that is documented but never performed. The audit evidence is the kind buyers and regulators accept, and the findings are ranked by risk, so fixes go where exposure is highest.
Commission an external cybersecurity audit once a customer or regulator asks for independent assurance.
Before that point, an internal cyber security audit against the same criteria is usually enough.
Audit vs assessment, risk assessment, vulnerability scan and pentest
A cybersecurity audit tests controls against a defined standard, while an assessment, a risk assessment, a vulnerability scan and a penetration test each answer a narrower question. The comparison below shows where they overlap.
An audit consumes the other four as evidence. A scan report supports a patch-management control, and a risk register shows whether the organization chose controls on purpose.
Penetration testing is one evidence source inside an audit, useful for checking whether controls hold under attempted exploitation. The penetration testing steps article covers how a pentest is run.
The risk rating of findings is where the activities most often get confused. A risk assessment rates threats to assets, and an audit rates control gaps against criteria, both by likelihood and impact. A scanner's severity score describes the flaw itself, so someone still has to translate it into business risk before it becomes an audit finding.
What types of cybersecurity audit are there?
Cybersecurity audit types are internal, external, compliance and third-party, and the trigger that prompted the audit should decide which one you run.
The four labels sit on two axes. Internal and external describe who performs the audit. Compliance describes the criteria: a framework or regulation the controls are tested against. A compliance audit can be internal or external. A third-party audit is an external audit whose report other people rely on, such as customers or regulators.
Ask three questions, in this order:
- Does someone outside the company need to rely on the findings? If a customer, regulator or insurer must trust the findings, commission a third-party audit. Use the criteria they name. If they name none, ask whether they accept SOC 2 or ISO/IEC 27001:2022.
- Does a law, contract or card-brand rule name a framework? Audit against that framework. The rule decides whether a self-assessment is enough or a qualified assessor is required. For PCI DSS, validation level decides.
- Is the driver a questionnaire that asks for no attestation? Run an internal audit against CIS Controls v8.1 or NIST CSF, led by a team independent of the control owners.
The table applies those questions to common triggers:
Re-run the questions whenever the trigger changes. Two early signs that an internal audit no longer fits: questionnaires start asking for a report or certificate, or a customer rejects your self-reported results. Either means the first question now answers yes.
An internal audit will not satisfy a customer who asks for independent attestation. It usually costs less than an external one, though, so we recommend running it first to find gaps before an outside auditor does.
Scoped audits narrow the boundary to one domain: network, application, identity and access, or cloud environments. They can be run internally or externally, and they fit teams that know where the risk sits.
Auditing your suppliers is a different exercise from being audited. It tests the controls of vendors that handle your data, usually through questionnaires, their attestation reports and targeted evidence requests. The vendor security evaluation guide covers that process.
What does a cybersecurity audit cover?
A cybersecurity audit covers twelve control areas, from governance and policies to security awareness, and tests each for design and operating effectiveness against the chosen criteria. The areas below map onto the safeguards in CIS Controls v8.1 and the other frameworks covered later. Each ends with a failure that tends to produce a finding.
- Governance and policies. The auditor traces each policy to an owner, an approval date and a review cycle. Failure mode: a signed policy with no evidence of review inside the audit period.
- Asset inventory. The inventory is checked against a second source, such as SSO app lists or cloud billing. Failure mode: shadow SaaS sits outside the scope boundary, so the audit signs off an incomplete system list.
- Identity and access management. A privileged access review samples admin, service and break-glass accounts, plus recent leavers. Failure mode: access reviews are approved in bulk, and stale accounts survive every cycle.
- Network security. Segmentation and firewall rules are examined against the documented design. Failure mode: temporary rules opened for a migration or incident never expire.
- Endpoint and configuration management. A configuration review against CIS Benchmarks compares live settings with the baseline, Level 1 for general systems and Level 2 for higher-risk ones. Failure mode: the baseline holds at build time, drifts afterward, and exceptions have no documented compensating control. Cloud accounts follow the same logic, and the cloud audit guide covers provider-specific checks.
- Data protection and encryption. Classification, encryption in transit and at rest, and key custody are tested. Failure mode: production data is encrypted, but copies in analytics or test environments are not.
- Application and API security. Auditors examine the secure development process, dependency handling and authorization checks. Line-by-line review belongs to a software audit. Failure mode: undocumented API endpoints that never entered the test scope.
- Logging and monitoring. The log retention period is compared with policy and with what an investigation would need. Failure mode: retention follows a storage default shorter than the policy states.
- Incident response. Auditors interview responders and examine the plan and past incident tickets. Failure mode: a plan exists, but no tabletop exercise or real incident record shows it working.
- Backup and recovery. Restore test records are sampled. Failure mode: backups run on schedule but nobody has restored from them, so the control is designed but unproven in operation.
- Vendor management. The vendor inventory, due diligence records and offboarding steps are examined. Failure mode: vendors are assessed at onboarding and never again.
- Security awareness. Training completion records are tested against the full employee population. Failure mode: contractors and new hires fall outside the population being measured.
How to conduct a cybersecurity audit step by step
A cybersecurity audit runs in seven steps: fix the scope and criteria, collect evidence, sample over the audit period, test design and operating effectiveness, rate findings, report, and retest.
- Fix the scope boundary and the criteria. Name the systems, entities, locations and audit period, and state what is excluded. Pick the criteria the controls are judged against, such as CIS Controls v8.1 or the Statement of Applicability under ISO/IEC 27001:2022. Without both, a finding cannot be reproduced by anyone else.
- Collect evidence with examine, interview and test. NIST SP 800-53A defines these three assessment procedures. Examine means reading policies, configurations and logs. Interview means asking control owners how the control runs and who covers it when they are out. Test means exercising the control, for example confirming that a deprovisioned account can no longer authenticate.
- Request the population, then sample. Sampling starts with the full population for the audit period: every access grant, change ticket or backup job. The auditor, not you, picks the sample. Sample size follows control frequency and risk, so a daily control gets more items than an annual one. A screenshot proves the state on one day, not that the control ran in March.
- Assess design, then operating effectiveness. Control design asks whether the control, run as written, would meet its control objective. Operating effectiveness asks whether it ran consistently across the period. A well-written quarterly access review passes on design and fails on operation if the third quarter was skipped. If a control fails, the auditor checks for a compensating control that still meets the objective.
- Rate each finding by likelihood and impact. Score both on the same scale, usually three or four levels, and record the criterion, the evidence and the cause. An unpatched internet-facing system with a known exploit rates high on both. The same flaw on an isolated lab host may rate low, because exposure changes the likelihood.
- Report with owners and dates. Each finding gets a named owner, a management response and a target date, so remediation can be tracked and does not depend on memory.
- Retest with new evidence. A closed finding needs fresh samples from the period after the fix. A written statement that the issue is resolved does not close it.
Netguru's security review of a US healthcare application subject to HIPAA shows the full loop. The review found several high-severity vulnerabilities, including one that left the client open to a breach. Netguru reported it immediately with a mitigation plan, measures were taken on each finding, the new backend was designed against the identified threats, and security inspection continued alongside functional work.
Which frameworks are cybersecurity audits run against?
A cybersecurity audit is run against one set of criteria, chosen by who needs the assurance: a customer, a regulator, a card brand, or your own board.
There is no NIST audit in the certification sense. NIST publishes the criteria, in the Cybersecurity Framework (CSF) and SP 800-53, and SP 800-53A defines the examine, interview and test procedures. An internal or third-party assessor does the work.
The frameworks side by side:
The Statement of Applicability matters in an ISO audit because the auditor tests only the controls it declares, and every exclusion needs a justification. A SOC 2 Type 2 report samples evidence across the audit period, so log retention and ticket history decide the outcome as much as the control design.
We recommend choosing by external obligation first: card data means PCI DSS, health data means HIPAA, and enterprise buyers usually ask for SOC 2 or ISO/IEC 27001:2022.
With no external requirement, CIS Controls plus CIS Benchmarks is a practical set to audit internally, and a crosswalk lets one evidence set serve several frameworks. This breaks down when a contract names a specific report type, which no mapping can replace.
Cybersecurity audit certification: What it means and what it doesn't
Cybersecurity audit certification means different things by framework: ISO/IEC 27001:2022 certifies a management system, SOC 2 attests to controls, and PCI DSS v4.0.1 validates compliance.
The three outputs prove different things, as the table shows:
Our recommendation is to ask the requester which document they accept before you scope anything. Reading a counterpart's report, check the scope boundary and the period covered first.
Security audit checklist: What an auditor will ask for
A security audit checklist pairs each control with an artifact, a named owner and a retention window, so an auditor can sample the evidence.
Sampling works the same way across frameworks. The auditor reads your policies to judge control design, then draws a sample from a population, such as every leaver in the audit period, to test operating effectiveness. If you cannot export the full population, the auditor cannot sample it.
The table below lists what to have ready. Retention values are our suggested defaults unless a rule is cited.
A privileged access review is the artifact auditors most often find incomplete. It needs the account list, the reviewer's name, the date, and a ticket for every removal or downgrade. A screenshot of an admin group does not show that anyone reviewed it.
The log retention period is the one place where a rule sets a number. PCI DSS v4.0.1 Requirement 10.5.1 requires at least 12 months of audit log history, with the most recent three months immediately available for analysis (PCI DSS v4.0.1, PCI Security Standards Council).
HIPAA requires six years of retention for required security documentation under 45 CFR 164.316(b)(2)(i). ISO/IEC 27001:2022 and SOC 2 set no fixed number, so the auditor tests against the period your own policy states.
A downloadable PDF checklist is a fine starting point. Convert it into a tracker where every row links to a live export, because evidence you can regenerate on request holds up better than a folder assembled the week before fieldwork.
Is there a cybersecurity audit PDF or template you can use?
Yes, free cybersecurity audit PDFs and spreadsheet templates exist, but a template is usable only if every row carries a criterion, an evidence artifact, a named owner, and a sample period.
A topic list such as "MFA enabled?" fails that test. It names no standard to judge against, no artifact to inspect, nobody accountable for producing it, and no date range for the population.
The audit checklist above already pairs controls with artifacts, owners and retention windows. Copy it into a spreadsheet, then add a sample period column and a status column.
For ISO/IEC 27001:2022 audits, the Statement of Applicability works as the criteria column. It lists each Annex A control, whether it applies, why, and its implementation status, so the auditor tests what you declared in scope.
NIST and CIS publish their control sets as downloadable documents. Those are criteria, not workpapers, so you add the evidence, owner and period columns yourself.
How do you prepare for a cybersecurity audit?
Prepare for a cybersecurity audit by fixing three things before the auditor arrives: the log retention period, a named owner for every control, and a scope boundary that includes shadow SaaS.
Sampling drives all three. The auditor draws samples from a population that spans the whole audit period, so evidence has to exist for every month in it, not only for today's configuration.
The failure modes, with a check you can run early:
The dry request is the cheapest of the three checks, and it also exposes weak evidence quality: screenshots with no date, exports with no query shown, and approvals held in chat.
One caveat: retention minimums vary by criteria. PCI DSS sets its own, covered in the checklist, while other frameworks leave the period to be agreed in scope. Settle that with the auditor in writing before fieldwork begins.
Internal or external audit: Which does a scaling software company need?
A scaling software company needs an internal audit from the first customer questionnaire onward, and an external audit once a customer, card brand, or regulator requires independent assurance. Until one of those triggers appears, an external audit costs money without anyone asking for the result.
The triggers and what each one requires:
An internal audit cannot give you independence. Even a rigorous one, run by someone outside the team that owns the controls, produces a result no customer or card brand will accept as attestation. It can still test design and operating effectiveness against any criteria you choose, which makes it the right tool for finding gaps.
An external audit cannot give you continuous coverage. The auditor samples from the audit period, writes an opinion, and leaves. It also cannot tell you which gaps matter most to your product, because its scope is set by the criteria.
We recommend running an internal audit against the same criteria one quarter before external fieldwork starts. That leaves time to fix findings and to gather evidence for every month of the period. Check the contract wording first: some customers accept an ISO certificate or a penetration test summary, and that can move the trigger later.
What happens after the report, and what to fix first
Fix findings by risk rating, meaning likelihood and impact, then reorder by exploitability: a reachable flaw under active attack outranks a higher-scored flaw on an isolated system.
The report's severity score cannot see exposure, so add that context yourself. Check whether the system faces the internet, whether the flaw appears in CISA's Known Exploited Vulnerabilities catalog, and whether the system holds regulated data. Our suggested order:
- Exposed, exploitable findings: internet-facing systems and anything on the CISA catalog.
- Findings that touch regulated data. Under the HIPAA Security Rule, the risk management standard at 45 CFR 164.308(a)(1)(ii)(B) requires reducing risk to a reasonable and appropriate level.
- Control design failures with cheap fixes, such as a missing MFA policy or an unwritten offboarding step.
- Operating effectiveness failures, such as skipped access reviews.
- Low-rated and informational items, batched into normal backlog work.
When a fix cannot land inside the remediation window, document a compensating control: a different safeguard that meets the same control objective, with a named owner, an expiry date, and its own evidence. The auditor tests it like any other control, so a compensating control without logs or review records will not close the finding.
Retest each finding against its original evidence. Design fixes can be verified the day they ship. Operating effectiveness fixes need a fresh population of runs, such as a full quarter of access reviews, before the auditor can sample them. Findings that recur across systems usually point to a gap in security architecture or in cybersecurity strategy, not in any single control.
What drives the cost and duration of a cybersecurity audit?
Audit scope, number of systems, framework, auditor type and remediation retest set the cost and duration of a cybersecurity audit. Effort follows the volume of evidence an auditor must collect and test.
Each system inside the scope boundary adds a population the auditor must sample. Testing operating effectiveness over a period, such as a SOC 2 Type 2 observation window, takes longer than a point-in-time design review, because the auditor samples evidence across the whole period.
The levers, and what happens when you pull them:
The cheapest reductions come from evidence readiness: named owners per control, retained logs, and exports that can be produced on request. These shorten fieldwork without changing what the auditor tests.
The unsafe reductions shrink scope to flatter the result. Auditor fee structures vary, so ask for a quote itemized by these drivers and compare on them.
How often should you run a cybersecurity audit?
Run a full cybersecurity audit at least once a year, and add continuous control monitoring between audits for the controls that drift fastest.
An annual audit tests design and operating effectiveness over a period. It matches the cycle of SOC 2 reports, ISO/IEC 27001 surveillance audits and PCI DSS assessments. The gap is the weakness: a storage bucket opened to the public or a skipped access review can sit unnoticed for most of a year.
Continuous control monitoring closes that gap with automated checks: configuration drift against CIS Benchmarks, MFA coverage, log-pipeline health. NIST CSF 2.0 places continuous monitoring in its Detect function (DE.CM), so these checks have a defined home in the framework.
Pipeline-level checks fit naturally into a DevSecOps workflow. Interviews, policy review and scope judgment stay manual, so monitoring feeds the audit as evidence and does not replace it.
We recommend an out-of-cycle audit, scoped to the change, after any of these triggers:
- A contained security incident or confirmed breach
- A major architecture change, such as a cloud migration, a new identity provider or a new region
- A merger, an acquisition, or a new regulated data type such as card or health data
- A new contractual requirement, such as an enterprise customer's security addendum
- A new third party with access to production data
HIPAA sets no fixed interval. 45 CFR 164.308(a)(8) requires periodic evaluation, and it also requires one after operational changes that affect the security of electronic protected health information. For most triggers, a scoped internal audit is enough; reserve the external auditor for what a framework or customer requires.
What is a cyber security audit?
A cybersecurity audit is a systematic, evidence-based check of an organization's security controls, policies, and configurations against a defined standard, ending in documented findings. The auditor examines documents, interviews control owners, and tests configurations to judge whether controls are designed and operating as stated. A review with no named standard to test against is a security assessment instead.
How much does a cybersecurity audit cost?
A cybersecurity audit's cost depends on scope, number of systems, framework, internal or external auditors, and whether a retest is included. A narrow internal review of one application takes far less effort than an external multi-framework audit. Ask for fixed-scope quotes tied to a written scope boundary, since open scope is how fees grow.
Is a cyber security audit mandatory?
A cybersecurity audit is mandatory only where a regulation or contract requires one. PCI DSS covers card data, HIPAA's Security Rule requires periodic evaluation (45 CFR 164.308(a)(8)), and enterprise customers often ask for SOC 2 or ISO/IEC 27001. Elsewhere an audit is voluntary, but a customer questionnaire can turn it into a sales requirement.
What are the different types of cybersecurity audits?
Cybersecurity audits vary by auditor and by scope: internal or external, compliance against a framework, or scoped to network, cloud, application, identity and access, or third-party security. Internal audits suit readiness checks, while external audits give independent assurance to customers and regulators. Choose by the question you must answer, such as a customer's SOC 2 request.
Is there a NIST audit?
NIST does not run audits or issue certifications; organizations are assessed against NIST CSF 2.0 or SP 800-53 by internal or third-party assessors. NIST SP 800-53A defines examine, interview, and test procedures that assessors use to check controls (NIST CSRC Glossary (assessment method)). Treat a "NIST compliant" claim as a statement about scope and assessor, and ask for the report.
Who can audit against NIST CSF?
Internal audit teams or independent third-party assessors can audit against NIST Cybersecurity Framework (CSF) 2.0, because NIST does not certify assessors. Internal teams fit readiness work; third parties give assurance customers and regulators can review. Check the assessor's experience with SP 800-53A procedures and independence from the team that built the controls.
Plan your next security audit with a clear scope
A cybersecurity audit starts with a written scope: the systems, control areas, framework and period it covers. Settle those four items before you request quotes, so every proposal is priced against the same boundary.
