Five Ways GRC Professionals Are Actually Using AI & the One Place I Will Not Put It

Key Takeaways

• AI Adoption in GRC: AI tools like Claude are already deeply embedded in day-to-day GRC work, often adopted informally by practitioners ahead of leadership awareness.
• Efficiency Gains Across Core Functions: Framework mapping, vendor risk analysis, policy drafting, and risk assessments are being significantly accelerated through AI-assisted workflows.
• Shift Toward Higher-Value Work: AI is reducing time spent on drafting and analysis, allowing professionals to focus more on judgment, calibration, and decision-making.
• Clear Boundary on Decision-Making: While AI enhances preparation and analysis, final decisions must remain with humans to preserve accountability and meet regulatory expectations.
• Risk of Leadership Lag: Organizations that continue to treat AI as a future issue risk falling out of sync with how their teams are already operating.

Deep Dive

About a year ago, a risk analyst on one of my client teams told me she had just reviewed a 94-page SOC 2 report in twelve minutes. She used Claude. She did it at her kitchen table at 9 PM because she had two kids and the workday had long since ended.

That was the moment I realized the GRC function had crossed a line, and that leadership in our field had not yet noticed.

AI did not show up in GRC through a steering committee. There was no budget line, no policy memo, no announcement from the chief risk officer. It showed up quietly, on personal laptops and in late-night vendor reviews. In the moments when an auditor or a risk analyst realized that a language model could read a dense document faster than a human being, and without getting tired on page 40.

Most GRC leaders I speak with still treat this as a future problem. It is not. It is a 2024 problem that is now deeply embedded in 2026. The people still calling it a future problem will be the last to realize that their teams have already moved on without them.

I wrote Supercharge Your Workday With Claude (2026) for those who want to learn how to use AI and for practitioners who are already leveraging it. Not a hype book. Not a fear book. Just the patterns that are working, with honest caveats, from someone who has been in cyber risk, audit, and compliance for more than twenty years and who uses these tools in live client engagements all the time.

Here are five patterns from the book. And one place I will not let Claude anywhere near.

1. Framework Mapping That Actually Uncovers Gaps

Mapping controls across NIST CSF, ISO 27001, SOC 2, HIPAA, PCI DSS, and whatever other alphabet soup your organization must comply with is one of the most tedious exercises in our field. It is also one of the most valuable. The mapping surfaces issues such as controls you have covered twice or controls you have not covered at all. Controls that look fine in ISO 27001 until you check what HIPAA actually requires at §164.308.

Two examples of what I mean by gaps. ISO 27001 Clause 6.1.2 requires an information security risk assessment. §164.308(a)(1)(ii)(A) requires a written risk analysis that specifically identifies threats and vulnerabilities to electronically protected health information and is documented in a way a regulator can read. Clause 6.1.2 will get you to roughly 60% of that requirement. The remaining 40% is exactly the kind of gap the U.S. Department of Health and Human Services flags during a HIPAA audit.

Second example. ISO 27001 Annex A.5.24 on incident response planning looks comprehensive on paper. §164.308(a)(6) adds specific requirements that the ISO control quietly assumes: your procedures must explicitly address suspected or known security incidents; your workforce must be trained to identify them; you must document each incident and its outcome; and the documentation must be retained long enough for a regulator to review it six years later. The ISO control asks you to plan. HIPAA asks you to prove.

Claude is unusually good at this kind of work when you provide context. Here is what I mean by context. Not a generic "map ISO 27001 to SOC 2." That produces generic slop. I paste the client's actual control language, list the three or four frameworks in scope, note the industry and the regulatory environment, and ask for a mapping matrix that lists the gaps at the top.

What comes back is a crosswalk, yes, but also a gap analysis. In one engagement, Claude identified two genuine gaps in their ISO 27001 coverage that their prior auditor had nodded through. An afternoon of work, not at the end of a quarter.

2. Vendor Questionnaire Analysis That Stops Accepting Vague Answers

Every GRC professional has received a vendor questionnaire in which half the responses read “we follow industry best practices” and the other half simply say “yes.” That is not a questionnaire. That is a press release with a header row.

Paste a completed SIG, CAIQ, or custom questionnaire into Claude and tell it to flag vague answers, call out coverage gaps, and suggest follow-up questions. The two-hour review becomes fifteen minutes. The follow-ups you send are sharper because Claude does not get tired on page 40 the way a human reviewer does.

More than once, I have watched Claude catch a vendor's careful non-answer about data at rest that three previous human reviewers had waved through. One of those vendors, to their credit, returned a real answer. The other two quietly disappeared from the procurement pipeline.

3. Policy Drafting That Is Tailored, Not Generic

Security policies live in a strange middle ground. Every organization needs them, yet no organization enjoys writing them. Most end up either copy-pasted from a template that does not fit or agonized over for months by a committee, producing a policy that also does not fit, but is just more expensive.

Claude splits the difference. Describe the organization, its risk profile, its regulatory posture, and any specific concerns or historical incidents. The draft you get back is not a template. It is a policy written for that environment, in language a non-technical employee can actually follow. You edit for accuracy, tone, and the specific terminology your organization uses. A week of drafting work becomes an afternoon.

One caveat, and the book makes this explicit. Claude does not replace a legal review. It gets you to a draft that is worth reviewing, much faster. Your general counsel can take care of the rest.

4. Regulatory Translation That Gets Actual Work Out of Legalese

Regulations are written by lawyers, for lawyers, and your IT team needs to know what to do on Monday morning. That translation layer is where most compliance programs fall apart.

Claude handles translation well. Share the regulatory text, a new NIST Special Publication, a section of the EU AI Act, and an update to the NY DFS cybersecurity regulation, and ask for a practical implementation checklist. What you get is not a legal interpretation. It is a starting point for your legal and technical teams to debate, which is what good compliance work has heretofore lacked.

One note for consideration. Claude is better at translating forward, regulation to action, than at translating backward, action to regulation. Do not ask it whether you are compliant. Ask it what compliance would require. The distinction is the difference between a useful tool and a problem waiting to happen.

5. Risk Assessments Accelerated by Real Context

A proper risk assessment is not something you outsource to a template. It requires judgment about which threats matter to an organization at that moment, given their posture, leadership, and budget. That judgment is not going anywhere.

What is going away is the time you used to spend drafting boilerplate, formatting findings, and reformatting the same assessment into three different reporting templates for three different audiences. Give Claude the context and scope, and it produces structured findings you can edit and deliver.

Here is a specific example. A client asked me last year to redesign their vendor risk management program. The program covered 200 vendors, used a basic questionnaire process, and lacked a systematic way to prioritize which vendors needed a deeper look.

Working with Claude, I built a tiered risk classification model, streamlined the questionnaire for low-risk vendors, developed a comprehensive protocol for high-risk vendors, and documented everything in about 2 hours.

That is not a typo. Two hours. Before Claude, that engagement would have consumed most of a week, and the first draft would have been worse than what we produced in an afternoon. As a result, my billable time went to calibrating the risk thresholds, tailoring the framework to the client's industry, and preparing for the board conversation where we would have to defend the design. The drafting work went elsewhere. The judgment work stayed with me.

The One Place I Will Not Put Claude: The Final Decision

Here is where I draw the line, and the book argues for drawing it firmly. AI belongs in the preparation, analysis, drafting, and review stages of GRC work. It does NOT belong in the final decision.

When a vendor is approved or rejected. When a control is signed off as effective. When a policy exception is granted. When a material finding is escalated to the board. Those decisions require human accountability, not because Claude would do them poorly, but because GRC is a profession built on attestation. Someone whose license, reputation, and livelihood rests on the judgment of the person making it.

An AI model cannot testify. It cannot be called before a regulator. It cannot sit for a deposition. That is not a technical limitation; it is a structural one, and it is the right structure.

This is why the book devotes an entire chapter to AI governance and responsible use, not a paragraph or an afterthought. The professionals who will be trusted with AI over the long run are those who, today, show they know where to draw the line. Your reputation as a thoughtful AI user is an asset; guard it.

The Takeaway

The question facing GRC professionals is no longer whether to use AI. It is about how to use it to improve the work without undermining the integrity of the profession. The five patterns above are starting points. The book builds on them, offering a full prompt library, chapter-by-chapter workflows, and a 30-day plan for integrating AI into your weekly routine without breaking anything.

If this makes sense to you, the book is available on Amazon: Supercharge Your Workday With Claude (2026). More than that, I hope you try one pattern this week to begin your journey. The people building the future of GRC are using these tools openly today and sharing what they learn.

A Note From the Author

I used Claude to draft portions of this article, which I then substantially edited based on my own practice. That is exactly how the book recommends using it, and writing a piece about AI for work any other way would have felt disingenuous. The content, the judgments, and the mistakes are mine.

About the Author

Norman J. Levine is Principal Consultant at Cyber Risk Partners LLC and a 20+ year leader in third-party risk management, cyber risk, and compliance. His enterprise career includes senior roles at Cigna Healthcare, Stanley Black & Decker, Omnicom Group, KPMG, and HBO. He is CISA and CDPSE certified, serves on the cybersecurity advisory boards of Pace University and Seton Hall University, and is the author of Supercharge Your Workday With Claude (2026), available on Amazon, and a forthcoming Taylor & Francis book on third-party risk management and data privacy. He can be reached at njlevine@gmail.com.

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey.