If your CPA does compliance, do you still need a pentest?

Your CPA firm hands you a thick cyber GRC report. Policies updated. Risks scored. Controls in place. The board meeting goes smoothly. Then one night your EMR, file share, or case management system is locked by ransomware, and everyone turns to you with the same question: we did all that compliance work, so how did this still happen?

That is the gap this article closes. Accounting-style cyber GRC shows what should work. Penetration testing, vulnerability scanning, and incident response prove what actually holds when attackers do not care about your paperwork.

The story behind cyber GRC: built by accountants, not attackers

Cyber GRC exists because boards, regulators, and auditors need a way to see cybersecurity in their own language. Governance, risk, compliance. That language came from accounting and audit long before it came from security engineers.

• Governance. Who is responsible, which committees exist, what gets reported, and how decisions are made.
• Risk management. Risk registers, scoring models, and treatment plans showing how you intend to handle threats.
• Compliance. Mapping your environment to HIPAA, SOC 2, ISO, or other frameworks and documenting the controls that satisfy each requirement.

The work product looks familiar to CFOs, controllers, and partners: policies and standards, risk registers and issues logs, control matrices and test plans, SOC reports and HIPAA risk assessments.

This is valuable. It gives you a coherent story for auditors and boards. But in a real attack, your adversary does not ask to see your policies. They ask your firewall, your VPN, and your identity systems whether you left a door open.

How origins shape outcomes

What accounting-style cyber GRC does best

• Documentation that stands up to audits: clean policies, clearly defined controls, traceable evidence.
• Regulatory alignment, with strong mapping to HIPAA, SOC 2, and other frameworks.
• Board and committee reporting that fits into governance packs.
• Financial framing that translates technical risk into business impact.

What offensive testing brings that GRC cannot

• Live exploit paths: demonstrated ways an attacker moves from the internet into your internal systems and data.
• Lateral movement: evidence of how far an attacker travels once they land.
• Misconfigurations and gaps where controls exist on paper but are inconsistently enforced.
• Scenarios modeled on how healthcare, legal, and professional organizations are actually being breached today.

Neither discipline is better than the other. If you report to a board, you need GRC. If you want to sleep through the night, you need your defenses tested by people who think like attackers.

Why GRC alone is no longer enough

A few years ago you could show auditors and insurers a risk assessment, some policies, and maybe a vulnerability scan, and call it good. Those days are over.

• SOC 2 guidance and leading assessors increasingly call for penetration testing and regular vulnerability scanning as part of a credible control set.
• HIPAA security resources recommend technical security testing to validate that documented safeguards actually work.
• Cyber insurers are tightening underwriting, often asking not just whether you have policies but whether you have tested your controls in the last twelve months.

GRC answers what should happen. Penetration testing and vulnerability scanning answer what actually happens when someone who knows what they are doing attacks you. Incident response answers what you do when they succeed anyway. If you hold PHI, legal files, or critical business data in Montana, regulators and carriers now expect all three.

Where are you today?

No real policies or risk framework yet

If your environment is still mostly tribal knowledge, start with baseline GRC: core security policies, a documented risk register, and a basic control framework mapped to your primary regulations. Once that is in place, schedule vulnerability scanning and scoped penetration testing so you do not mistake neat documentation for actual protection.

Binders of GRC, no offensive testing history

This is where many Montana healthcare and professional firms live. HIPAA risk assessments or SOC 2 workpapers, policies updated annually, maybe some scanner reports from your MSP — but nobody has ever been hired to attack your systems in a controlled way. Your next investment should be manual penetration testing and structured vulnerability scanning, not another GRC refresh. You already know what should happen. You need to know where it breaks.

Aiming for a crisis-ready posture

The mature end state for a Montana clinic, law firm, or business combines integrated cyber GRC, regular manual penetration testing with automated vulnerability scanning tied back to your control framework, and an incident response plan backed by a Montana-based team that already knows your environment.

How we differ from CPA-led cyber GRC

Most CPA firms that do cyber come at it from one direction. They start with GRC and sprinkle in scanning. Offensive testing and real incident response are bolt-ons, if they exist at all. We came up the opposite way.

We started as Montana's healthcare and professional services crisis response specialists. Our first job was handling live incidents, performing digital forensics, and running penetration testing in environments where downtime meant canceled appointments and missed court deadlines. We built GRC on top of that field experience, so your policies and risk registers reflect what actually happens under pressure.

Most CPA-led practices cannot follow an attacker step by step from an exposed service to domain compromise. Most pure hacking shops cannot sit in front of your board and explain HIPAA, SOC 2, and risk appetite. We do both.

Where we stand next to your CPA

On an ordinary day, your cyber GRC binder is a governance tool. On the worst day of your year, it is a reference document. What you need then is a crisis team that already knows your environment, your controls, and your people.

Your CPA firm can and should continue to lead on financial statements, and may support parts of your SOC or HIPAA documentation. We stand beside them as your cybersecurity specialists. Share your existing GRC and SOC work with us and we will show you where offensive testing and incident response should plug in, so you are not relying on accounting-style reports when prevention fails.