Vulnerability assessment and penetration testing are different scopes
A vulnerability assessment looks for known weaknesses and reports them. Penetration testing tries to exploit agreed weaknesses to show what an attacker could reach. NIST Special Publication 800-115 treats vulnerability identification and vulnerability validation, including penetration testing, as different techniques. Buying one does not deliver the other.
Mojave’s Security Baseline & Resilience Assessment includes a vulnerability review of the agreed external surface. It does not include exploitation, social engineering, or an attack simulation.
What each engagement is for
| Vulnerability review | Penetration test | Mojave baseline | |
|---|---|---|---|
| Purpose | Find and describe known exposures | Show what an attacker could do, within written rules | Give management a prioritized plan for the agreed environment |
| Exploitation | No | Yes, and only where authorized | No |
| Authorization | Named systems and a time window | Written rules of engagement | A written proposal accepted before work starts |
| Typical output | A list of weaknesses and severity | An attack narrative plus findings | Findings, a risk register, a roadmap, and an executive briefing |
Why the distinction matters for a professional firm
A CPA firm that has just failed a phishing test, or that needs a written plan for client information, usually needs to know whether multifactor authentication, mailbox rules, admin rights, and backups are in place. A vulnerability review of the external surface can be part of that picture. A penetration test that proves an outdated service can be exploited does not answer who can reset a partner’s mailbox.
Penetration testing is the right scope when a contract, customer, or insurer specifically requires evidence of exploitability, the systems are named, and the firm accepts the operational risk of an authorized attack. It is a weak first purchase when basic identity and backup questions are still unanswered. NIST SP 800-115 also expects testing to be planned, authorized, and matched to the technique. An unscoped “pentest” of a live tax system during filing season is not a responsible reading of that guidance.
What a scan does not settle
A scanner reports missing patches, exposed services, and known vulnerable software on the targets it was allowed to see. It does not interview the managing partner, read the written security program, or decide which finding would stop payroll. It can miss systems that were left out of scope, and it can flag items that are mitigated by a control the scanner cannot see. Those limits belong in the report. Treating the scan as the whole risk assessment overstates what the tool did.
The broader management question is covered in what an independent cybersecurity assessment includes. For accounting firms, the written program that should sit beside the technical review is covered in what a WISP needs to contain.
How Mojave treats penetration testing
Authorized penetration testing is considered only when a client requirement justifies it, under written rules of engagement and a qualified delivery arrangement. It is not included in the baseline fee, and it is not offered as an open-ended attack against systems that were never named. If a firm needs that scope, it is a separate conversation after the environment and the authorization are clear.
Source
Questions buyers ask
Which of these is included in Mojave’s baseline assessment?
The Security Baseline and Resilience Assessment includes a vulnerability review of the agreed external surface, plus review of identity, email, workspace, endpoint, backup, and incident-preparedness evidence. It does not include exploitation, social engineering, or an attack simulation.
Can a vulnerability scan replace a risk assessment?
No. A scan is one input. It does not explain who owns privileged access, whether backups restore, how the firm would respond to fraud, or which findings matter to the business. Those questions are what the management briefing is for.
When is penetration testing the right scope?
When a contract, insurer, or risk decision requires proof of what an attacker could reach, and only after the systems and rules of engagement are written down. It is a poor first purchase for a firm that does not yet know whether multifactor authentication, mail controls, and backups are in place.