How to scope a bias audit before you commission one
Most organizations ask for a "bias audit" long before they have agreed on what, exactly, is being audited. That ambiguity is where audits go wrong — they run over budget, produce findings nobody can act on, or test the wrong thing entirely. Scoping is the unglamorous work that determines whether the audit is worth doing. Here is how to do it well, whether you run the audit internally or bring in an independent reviewer.
Start with the decision, not the model
A bias audit is not really an audit of an algorithm. It is an audit of a decision that the algorithm influences — who gets hired, who gets a loan, who gets flagged for review. Begin by writing one sentence: "This system helps decide __ for ____." If you cannot finish that sentence cleanly, you are not ready to audit yet, because you do not yet know whose outcomes matter.
This framing also tells you which law or standard is in play. A tool that screens job applicants in New York City sits under Local Law 144. A model that affects credit decisions raises fair-lending considerations. The decision determines the rules, and the rules shape the audit.
Define the protected groups and the comparison
Bias is measured by comparing outcomes across groups. So scoping must name those groups explicitly — typically by characteristics such as race, sex, age, or disability status, depending on the context and what the relevant law requires. Two practical questions follow: do you actually hold the data needed to identify those groups, and if not, how will the audit estimate them? Many audits stall here, because the organization has never collected the demographic data the audit depends on. Surfacing that gap during scoping, rather than mid-audit, saves weeks.
Choose the fairness measures in advance
There is no single definition of fairness, and different measures can disagree. An audit can check whether selection rates are similar across groups, whether error rates are balanced, or whether the system is equally accurate for everyone — and a model can pass one test while failing another. Pick the measures that match the decision and the regulation before you see results. Choosing them afterward invites the appearance of selecting whichever metric makes the system look best.
Set the threshold for "a problem"
Decide ahead of time what level of disparity triggers concern and what happens next. A widely used reference point is the four-fifths rule, where one group's selection rate falling below 80 percent of the highest group's rate signals a possible adverse impact. Whatever benchmark you use, agree on it during scoping. An audit that produces numbers but no agreed line for action produces arguments, not decisions.
Decide what the deliverable is
Name the output before work starts. Is it an internal report for the model team? A summary suitable for a regulator? A published results page, as some laws require? The audience changes the level of documentation and the tone. An audit written for engineers and an audit written for a regulator are different documents, and discovering that after the analysis is done means rewriting it.
Protect independence
If the audit's conclusions could be uncomfortable, the people who built or profit from the system should not be the ones grading it. Independence does not require an outside firm in every case, but it does require that the reviewer can report an unfavorable finding without it costing them. Decide who that reviewer is, and what authority their findings carry, while scoping — not after.
A short scoping checklist
Before commissioning a bias audit, you should be able to answer: What decision does this system affect, and for whom? Which groups are we comparing, and do we have the data? Which fairness measures apply, and what disparity counts as a problem? Who is the audience for the findings, and what form do they take? Who runs the audit, and can they report bad news freely?
If those five answers are clear, the audit itself becomes far more straightforward — and far more likely to produce something you can actually use.
This guide is general information, not legal advice. The frameworks and thresholds that apply to your organization depend on your jurisdiction and use case. For a scoped assessment of your situation, get in touch.