Regulatory status current as of 3 September 2026.
Most things sold as cyber security audit services are not audits, and the distinction decides who is even permitted to perform the work. A vulnerability scan is a tool report. A penetration test is a scoped attempt to break in. A security assessment measures your controls against a framework. A risk assessment weighs threats against your assets and business context. A formal audit or attestation, meaning SOC 2, ISO 27001, PCI DSS, or CMMC, must be performed by an independent qualified party because the standard itself requires it, and no managed services provider can issue one for you. Red teaming tests whether your team would notice. Those are six different purchases with six different price points and six different deliverables. We recommend you identify which one your situation actually calls for before requesting a single proposal, because providers will happily sell you whichever one they offer.
Overview
- The word audit is used loosely. Six distinct services share the label, and buyers routinely pay for one expecting another.
- Independence is a hard requirement for attestations. SOC 2 comes from a CPA firm, ISO 27001 from an accredited certification body, PCI from a QSA, CMMC from a C3PAO.
- Your incumbent provider cannot objectively audit its own work. Even for informal assessments, that conflict is real.
- Start from the driver, not the service. A customer questionnaire, a regulator, an insurer, and a board each require different evidence.
- The deliverable is what you are buying. Prioritized findings with evidence and a remediation path, not an exported tool report.
The 5 Why’s
This is written for IT directors, security leads, compliance officers, and executives at organizations between roughly one hundred and a few thousand employees who have been asked to produce evidence of their security posture and are now trying to work out what to buy.
The request almost always arrives from outside. A customer sends a vendor security questionnaire that asks for a recent assessment or a SOC 2 report. An insurer’s renewal application asks whether you have had a penetration test in the past twelve months. A prime contractor’s flow-down clause references a compliance framework. A regulator opens an examination. A board member reads about an incident in your sector and asks what your exposure is. Each of those requests points at a different service, and answering with the wrong one wastes the money and does not satisfy the requester.
Sector conditions shape the specifics. Healthcare organizations face HIPAA risk analysis obligations, and OCR’s third phase of compliance audits is underway with an explicit focus on risk analysis and risk management. Financial services firms face examiner expectations and third-party risk programs from their own customers. Defense suppliers face NIST 800-171 and CMMC obligations. Organizations taking card payments face PCI DSS. Manufacturers increasingly face customer-imposed requirements with no regulator behind them at all.
The consequence of buying wrong is a report that does not answer the question you were asked, purchased on a deadline, with the real work still ahead of you.
Six Things Sold as a Cyber Security Audit
Vulnerability scanning. Automated identification of known weaknesses across your systems. Fast, inexpensive, and best run continuously rather than annually. The output is a list of findings by severity. It is a useful input to everything else and it is not an audit.
Penetration testing. A skilled tester attempting to achieve a defined objective in your environment within a scoped engagement. The value is in what a human finds that a scanner cannot: chained weaknesses, logic flaws, and privilege paths. Ask whether the engagement is genuinely manual, because some offerings sold as penetration tests are scan output with a narrative wrapped around it.
Security assessment or gap analysis. A review of your controls against a named framework, typically the NIST Cybersecurity Framework, CIS Controls, or a regulatory standard. The output is a gap list and a roadmap. This is what most organizations actually need first, and it is what we deliver as an IT assessment.
Risk assessment. Assets, threats, likelihood, and impact evaluated against your business context, producing prioritized risk decisions rather than a control checklist. HIPAA requires this specifically, and OCR has repeatedly found organizations substituting a gap analysis for it. They are not the same document.
Formal audit, attestation, or certification. An independent qualified party examining your controls against a defined standard and issuing a report with an opinion. SOC 2 reports come from CPA firms under AICPA standards. ISO 27001 certification comes from an accredited certification body. PCI DSS reports on compliance come from a Qualified Security Assessor. CMMC assessments come from a Certified Third-Party Assessment Organization. Independence is built into each of these, which means your managed services provider is structurally ineligible to perform them for you.
Red teaming or adversary simulation. An exercise testing whether your detection and response capability works, not whether vulnerabilities exist. Appropriate for organizations with a mature security program and wasted on organizations without one, because it will confirm what a cheaper assessment would have told you.
Can Your Current IT Provider Audit Your Environment?
For anything you will show a third party, no. For internal improvement work, with caveats you should understand.
The formal cases are settled by the standards themselves. A SOC 2 report requires a licensed CPA firm. ISO 27001 certification requires an accredited certification body. PCI DSS requires a QSA for the relevant validation level. CMMC requires an authorized assessment organization. If a provider offers to give you any of these directly, that is a reason to stop the conversation, because it indicates either a misunderstanding of the standard or a willingness to misrepresent it.
The informal case is more nuanced and worth being honest about, including about ourselves. When a provider assesses an environment it manages, it is grading its own work. Even with good intentions, findings that implicate the provider’s own decisions, tooling choices, or unmet commitments are less likely to appear, and the provider has a commercial interest in findings that lead to additional services it sells. That does not make the exercise worthless. It makes it an internal review rather than an independent assessment, and it should be described as one.
The practical arrangement most organizations land on separates the roles. An independent firm performs the assessment or attestation, and your provider remediates against the findings and produces the ongoing evidence. That split works well and it is how the compliance ecosystem is designed to function. Organizations with internal audit or compliance functions can run the assessment internally and use an external party only where a standard requires independence. Organizations under a single framework with a single customer demanding it should ask that customer what form of evidence they will accept, since some accept a self-assessment or a provider-issued report and others will not, and that answer determines the spend.
What we recommend you do about it:
- Ask any prospective auditor what they also sell you. Assessment and remediation performed by the same party carries a conflict you should at least price into how you read the findings.
- Verify the credential, not the claim. CPA firm registration, certification body accreditation, QSA listing, and C3PAO authorization are all publicly verifiable. Check them.
- Ask your requester what evidence they will accept. A customer that will take a completed questionnaire does not require a SOC 2, and finding that out first can save a great deal.
- Separate the assessor from the remediator where it matters. Independent assessment, internal or provider-led remediation, is the standard pattern for good reason.
- Treat a free audit as a sales document until proven otherwise. Often accurate, always scoped by a party with an interest in the conclusion.
Which Type Do You Actually Need?
Work backward from who asked and what they will accept. That single step eliminates most of the confusion and most of the wasted spend.
A customer security questionnaire usually calls for a security assessment against a recognized framework, or a SOC 2 report if the customer is large enough to insist. Ask before assuming the expensive answer.
An insurance renewal typically asks about specific controls and about whether a penetration test has been performed recently. Read the application, because it names what it wants.
A regulator or examiner requires whatever the framework specifies, and substitutions do not work. Healthcare organizations need a genuine risk analysis, not a control gap list, and that distinction has featured repeatedly in enforcement.
A prime contractor’s flow-down points at NIST 800-171 or CMMC. Note that the CMMC program changed materially in July 2026, when third-party certification requirements were suspended pending review while self-assessment and annual affirmation obligations remained in force. Read your actual contract rather than the headlines. See our CMMC compliance services.
A board or an executive question is usually best answered by a risk assessment, because it translates technical posture into business terms leadership can act on.
One caution specific to this year. Vendors are actively selling readiness services for the proposed HIPAA Security Rule update as though it were settled law. It is not. The rule remains at the proposed stage, the original target for final action passed without publication, the federal agenda now points to 2027, and a coalition of more than a hundred hospital and provider organizations has asked HHS to withdraw or narrow it. The existing Security Rule remains fully in force and is what OCR is enforcing. Preparing for stronger requirements is sensible on its own merits, since encryption, multi-factor authentication, and a functioning risk management program are worth having regardless. Buying compliance against a rule that does not exist yet is not, and a vendor presenting the proposal as current law is telling you something about how they sell. See our healthcare IT compliance work for the current position.
What we recommend you do about it:
- Get the requirement in writing from whoever asked. Framework, scope, and acceptable evidence format, before you shop.
- Do not buy a penetration test to answer a governance question. Testing exploitability tells leadership nothing about risk posture.
- Do not buy a gap analysis where a risk analysis is required. They look similar, cost similarly, and only one satisfies certain regulators.
- Run a scan before commissioning a test. Paying a skilled tester to find missing patches wastes the engagement on work a tool does better.
- Check whether a rule you are being sold against is actually final. If a proposal cites a pending regulation as current, ask directly.
What Should the Deliverable Contain?
Findings with evidence, prioritization tied to your business rather than to a severity score, a remediation path with owners and effort estimates, and a retest provision. A deliverable missing those is a document rather than a service.
Evidence matters because findings without it cannot be acted on or disputed. You should be able to see what was tested, how, when, and what was observed. Scope should be stated explicitly, including what was excluded and why, since an assessment that quietly omitted your most important system is worse than none. Prioritization should reflect exploitability and business impact rather than sorting a scanner’s severity ratings, and a good assessor will tell you which findings to ignore as well as which to fix.
Expectations should differ by service type. A penetration test report should include reproduction steps and evidence for each finding and a retest after remediation, and if retest is not included you should ask why. An assessment against a framework should map each finding to the specific control it fails and produce a plan of action you can maintain, since for several frameworks that plan is itself a required artifact. A formal attestation produces a standardized report whose form you cannot negotiate, and the work you should focus on there is readiness beforehand rather than the report format. For any of them, insist on receiving the underlying documentation and configurations in a usable form, because you will want them when you next change providers.
What we recommend you do about it:
- Ask to see a sample deliverable before contracting. Redacted is fine. The quality of the sample predicts the quality of yours.
- Require explicit scope, including exclusions. What was not tested is as important as what was.
- Insist on retest for penetration tests. Fixing a finding you cannot verify is fixed leaves you where you started.
- Require a maintainable plan of action, not a static report. Owners, dates, and closure evidence, in a format you can keep current.
- Confirm you own the outputs. Documentation, diagrams, and configurations should be portable in a usable format.
Security Audit Expertise from Matt Rosenthal
In 30 years of building security programs, I have read a lot of documents called audits that were scan exports with a cover page. What I have seen firsthand is organizations paying real money for a report that answered a question nobody had asked, because the requirement came from a customer and nobody checked what that customer would actually accept. Our team starts by reading the request that triggered the project, and we will tell you when the right answer is an independent firm rather than us, because for anything you will show a third party that is the only answer that holds up. Ask what evidence your requester needs before you buy anything. See our cybersecurity services and IT assessment process.
How to Run the Purchase
The organizations that buy this well do one thing first. They go back to whoever asked for the evidence and get the requirement in writing: which framework, what scope, what form of report, and by when. That single conversation resolves most of the ambiguity and frequently reveals that the expensive option is not required.
Then match the service to the requirement rather than to what a provider leads with. A questionnaire and a regulator want different artifacts. An insurer wants specific controls confirmed. A board wants risk in business language. Then verify credentials wherever independence is required, because those are publicly checkable and the consequences of an invalid report land on you rather than on the firm that issued it.
Then look hard at the deliverable, ideally at a real sample, and confirm it includes evidence, honest scope, prioritization you can defend to leadership, and a remediation path someone can own. Whether you buy cyber security audit services from us, from an independent firm, or from both in the correct sequence, the report is the product, and it should be judged as one.
If you have been asked for evidence and are not sure what would satisfy the request, that is the place to start rather than with proposals. Contact Mindcore to talk through what your requester actually needs.
