The use of AI in GRC is a common topic; there's broad agreement that the technology should be able to help with a wide range of both labour intensive and analytical tasks - but no clear consensus, pattern or library of guidance on how best to apply it. More broadly, there has been significant effort applied to creating a number of repeatable prompt structures (e.g. CO-STAR, RISEN, RTF, etc...) but as the old joke goes - the great thing about standards is there are so many to choose from.
What nobody seems to have done yet is test them on GRC work. There's a growing body of research on how prompt format and reasoning style affect AI output, but I couldn't find any about applying it to risk registers, control testing or regulatory scanning.
Thinking is starting to move in this direction, though. In August 2026 NIST published a draft quick-start guide, SP 1353, on using AI for CSF 2.0 analysis and reporting. It includes structured example prompts for tasks like reviewing governance documents and drafting current and target state profiles. NIST is careful to present these as illustrations, and doesn't claim they're tested best practice, but it's a good sign of where practitioner guidance is heading.
So this is a first estimate. It draws on what the general research shows, translates it into GRC activities, I've also tried to be as open as possible about which parts are evidenced and which are informed judgement (or a professional guess if you prefer). Treat it as a starting point for your own testing.
What the research shows
Three findings stood out.
Format matters, and nothing wins everywhere. Changing only the layout of a prompt can move results a long way. One study saw accuracy swing by up to 76 points on an open-source model from formatting changes alone, and the effect persisted in larger models. Another found GPT-3.5's results varied by up to 40% between plain text, Markdown, JSON and YAML, while GPT-4 was steadier. Neither found a format that came out on top across the board.
The "best" format is model specific. The format that works best for one model only weakly predicts what works best for another. A prompt tuned carefully for today's model may be ordinary on next year's.
Task type changes the picture. Asking a model to reason step by step gives strong gains on maths and logic, and much smaller gains elsewhere. For extraction and classification, simple prompts with good examples often beat elaborate ones, and added reasoning can make simple classification worse. Judgement-heavy tasks are where reasoning style starts to make a difference.
Three layers in every prompt
It helps to separate three things that most guidance blends together.
Format is the presentation: plain text, Markdown, JSON or XML tags. This is what the format studies above tested.
Structure is how the instruction is packaged: the sections you fill in and the order they come in. This is what CO-STAR and its cousins describe. Named frameworks have barely been compared against each other. The one study I found that did saw CO-STAR and RISEN score within 0.05 points of a third framework, and the authors suggest even that gap may come down to prompt length.
Reasoning approach is how you ask the model to think: weigh the evidence, test a claim, or argue the other side.
Format can swing results a long way, but unpredictably from model to model. Named structures seem to make little difference to quality. Reasoning approach has more influence on judgement tasks, though the best choice varies from model to model. Keeping the layers apart lets you standardise the first two and vary the third.
Structures to choose from
| Structure | Sections | Suits |
|---|---|---|
| RTF | Role, Task, Format | Short, frequent tasks. The easiest to adopt. |
| CO-STAR | Context, Objective, Style, Tone, Audience, Response | Outputs written for a specific reader |
| RISEN | Role, Instructions, Steps, End goal, Narrowing | Procedural work with defined steps or criteria |
| RACE | Role, Action, Context, Expectation | A middle ground between RTF and CO-STAR |
| Tagged sections | Labelled blocks (for example XML tags) for instructions, data and output | Keeping instructions clearly separate from the material being analysed |
| Plain + examples | An instruction plus a few worked examples | Extraction and repeatable formats |
Most of these frameworks grew up informally, so you'll find slightly different expansions depending on where you look. The labels matter less than picking one and using it consistently.
Reasoning approaches
People have been working out how to reason well for a very long time. Weighing evidence, testing a claim, arguing the other side: philosophers gave each of these a name, and each makes a surprisingly good instruction for an AI model. Here they are in plain English, with a note on where each one tends to help.
| Reasoning approach | What it asks of the model | Best-fit mode | Philosophical root |
|---|---|---|---|
| Evidence first | Conclude only what the material shows | Gathering | Empiricism (Hume) |
| Criteria check | Judge strictly against stated criteria | Evaluation | Rule-based judgement (Kant) |
| Sceptical reviewer | Look for contradictory evidence, and accept a claim once it's demonstrated | Evaluation | Methodical doubt (Descartes) |
| Guided questioning | Draw out the answer through questions | Interactive | Socratic method |
| Challenge and resolve | Argue the opposite case, then reconcile | Interactive | Dialectic (Hegel) |
Researchers have started testing these directly. A 2026 study built prompts around Socrates, Descartes, Kant and Hume and found real gains on scientific reasoning, with the best approach depending heavily on the model. Separate work on dialectical self-critique found it particularly helpful on structured, rule-based reasoning. Both used structured, multi-step reasoning processes, so whether a simple instruction gives similar gains on GRC tasks is still to be tested. The upshot is these are a useful layer to be able to apply on top of a specific task based prompt depending on the role you want the AI to play.
Three kinds of GRC activity
Most AI use in risk and compliance falls into one of three modes.
Gathering. Collecting and extracting: pulling dates, owners and outcomes from evidence, scanning for regulatory change, or extracting obligations from a standard.
Evaluation against criteria. Judging something against a defined standard. Does this control design meet our criteria? Does this evidence show the control operated? Does this policy conform?
Interactive reasoning. Thinking alongside a person over several turns: working through an RCSA with a risk owner, or challenging a score before it goes to committee.
These are primary working modes, and real work often moves between them. A control assessment might gather evidence, evaluate it against criteria, then talk the result through with the control owner.
Here's how that might look for a few common tasks:
| GRC task | Mode | Approach | Quality check |
|---|---|---|---|
| Extract obligations from a standard | Gathering | Evidence first | Complete and traceable |
| Assess control design | Evaluation | Criteria check | Criteria applied faithfully |
| Draw out a risk owner's rationale | Interactive | Guided questioning | Rationale recorded |
| Challenge a residual score | Interactive | Challenge and resolve | Alternatives considered |
Each mode suits different reasoning approaches, and that's where the map comes in.
A first map
The map plots each reasoning approach by the activity it suits and the tier of model where it adds most value. Treat it as a hypothesis map for testing. Tiers use model families, since version numbers change every few months:
- Frontier: Claude Opus, GPT flagship models, Gemini Pro
- Mid-tier: Claude Sonnet and Haiku, Gemini Flash, GPT mini variants
- Small or local: Llama, Qwen, Phi and Mistral's smaller models
The fill shows how much evidence sits behind each position. Filled markers rest on published findings. Light markers have partial support. Outlines are inferred from related research and my own judgement. "Straight answer" is a plain prompt with no reasoning approach, included as a baseline.
A few things stand out.
Evidence first looks safe at every tier. The research shows simple, example-led prompts work well for extraction regardless of model size. An explicit evidence-first instruction hasn't been tested on its own, which is why its marker is light.
Guided questioning also spans the tiers. Guided questioning (Socratic) prompting gave the largest gains on smaller models in the research, and still added 14 points for one frontier model.
Challenge and resolve sits with the frontier. Arguing against your own answer and then reconciling the two is demanding work. My suspicion is that weaker models will flip between positions and settle on whichever came last.
Small models are thin on the ground for interactive work. Long, multi-turn reasoning is hard for them, and the map reflects that. They may cope with lighter conversational work, but I wouldn't rely on them as independent evaluators.
Picking your house style
Here's the practical conclusion. If no structure reliably wins, and the best one doesn't carry between models, the biggest gain comes from familiarity in the team that is drafting them.
GRC teams already know this logic. Most organisations standardise how risks are written, often as cause, event and consequence. This makes comparison, review and aggregation much easier. Prompts work the same way. A shared structure means colleagues can read each other's prompts, improve them, reuse them, and spot where one has gone wrong.
So a reasonable house style looks like this:
- One structure, chosen by your team for its fit with how you already work - or simply the one that your team finds easiest to relate to if you're introducing this as a new approach.
- Two or three reasoning approaches from different areas of the map, covering your main activities. For example, Evidence first for gathering, Criteria check for evaluation, and Guided questioning for workshops.
- A small set of test scenarios drawn from your own risks and controls, so you can check a change before rolling it out. Twenty real examples with clear acceptance criteria, including a few awkward edge cases, will tell you more than any benchmark. Grow the set as the stakes rise.
That last point matters more as models change. When you move to a new model, rerun your scenarios. The research says the best prompt may have moved with it.
It's also worth being clear about what prompting can't do. No prompt compensates for missing evidence, vague control criteria, the wrong reporting period or unreliable source data. Prompt standards sit alongside the usual safeguards: knowing where the data came from, validating outputs, review, and a route to escalate when something looks wrong.
Next: putting it to work
In the next post we'll apply this to a real workflow: an evidence-gathering pipeline where each stage uses a different mode, from screening the material, through extraction and evaluation, to recording the result.
Sources
- NIST (2026), SP 1353 (Initial Public Draft): NIST Cybersecurity Framework 2.0: Quick-Start Guide for Using Artificial Intelligence (AI) for CSF Analysis and Reporting
- He et al. (2024), Does Prompt Formatting Have Any Impact on LLM Performance?
- Sclar et al. (2024), Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design
- Sprague et al. (2025), To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning
- LLMs are not Zero-Shot Reasoners for Biomedical Information Extraction
- Task Complexity Matters: An Empirical Study of Reasoning in LLMs for Sentiment Analysis
- Structured Intent as a Protocol-Like Communication Layer: Cross-Model Robustness, Framework Comparison, and the Weak-Model Compensation Effect
- Which Prompting Technique Should I Use? An Empirical Investigation of Prompting Techniques for Software Engineering Tasks
- The ballad of LLM agents: philosophical reasoning for chemistry
- Self-reflecting Large Language Models: A Hegelian Dialectical Approach
Tom Whipp is the founder of RiskQuilt. He spent around thirty years in cyber and technology risk in UK financial services, including CISO and Director of Technology Risk roles.