SOX control narrative drafting

A SOX control narrative is a process owner's description of how a control operates: who performs it, what they review, how often, which systems hold the evidence, and how exceptions are cleared. An LLM draft is a proposed rewrite of that description. It is not a new control, not a signed assertion, and not a substitute for the owner's walkthrough.

The only legitimate change is language that reflects a documented process change against a known prior version. If the prior narrative is missing, or if there is no process-change note, the draft stays empty. Filling the page from general knowledge of how AP typically works invents a control the company may not run.

The quality bar is narrow and checkable: the draft cites the prior version and the process-change note. Those cites must be visible in the draft itself, as version IDs, dates, or document titles the owner already recognizes. A fluent paragraph without those cites is not a SOX-ready draft.

Control narratives often live next to evidence packages and workpapers. Retrieval of source files is a different job than rewriting the narrative. Pair this work with a control-evidence retrieval agent when the owner needs the attachments, not the prose.

Do not prompt the model until two artifacts sit in the same working set.

First, load the last signed or last circulated narrative for that control ID. Prefer the version stored in the GRC or SOX workspace. Tools in this class, including AuditBoard, hold control documentation; ERP and close systems such as Workday, SAP, and BlackLine may hold overlapping procedure text. Treat those copies as secondary when they drift. The prior version is the one the owner last accepted, not the longest wiki page that mentions the process.

Second, load the process-change note that triggered the rewrite. That note is usually a change ticket, a system cutover memo, a RACI update, or a walkthrough finding that the existing wording is wrong. It must name the control or the process step. A generic message that finance implemented a new tool is not a change note for a specific control.

If either artifact is absent, stop. Empty output is the correct output. Do not backfill from a similar control, from last year's narrative for a different ID, or from a vendor sample library.

When both artifacts are present, record their identifiers in the prompt or the draft header: prior narrative ID and date, change-note ID and date. Those identifiers become the cites the owner will check.

Downstream review of the workpaper that attaches this draft is a separate step. A workpaper review LLM can flag missing cites. It cannot approve the control.

Work in this order.

1. Quote or attach the prior narrative and the change note as source blocks the model cannot ignore.
2. Instruct the model to produce a full narrative only where the change note actually amends the prior text. Preserve unchanged sections verbatim, or mark them unchanged from prior.
3. Require inline cites on every amended sentence: which prior paragraph and which change-note line the sentence rests on.
4. Require empty fields (frequency, performer, system, evidence location) wherever the sources do not state a value.
5. Route the draft to the process owner. The owner edits, then signs. The model does not sign.

Illustrative example, not a measured result. Control AP-04's prior narrative says the AP manager reviews a system-generated three-way match exception report weekly, in SAP, and clears items over a stated threshold. A change note dated 12 March records that exception review moved to a daily BlackLine reconciliation owned by the AP supervisor, with the same threshold. A valid draft rewrites performer, cadence, and system, citing AP-04 prior v3 and the 12 March note. It does not invent a new matching control, a new dollar threshold, or a compensating review by Internal Audit. If the change note is silent on the threshold, the threshold line stays as in the prior, or stays blank if the prior also omitted it. If there is no AP-04 prior and no change note, the draft is empty. The owner writes the first narrative by hand.

That pattern is the whole method: two sources, a bounded rewrite, blanks where sources are silent, owner signature after the draft.

Narrative updates sometimes coincide with journal-entry process changes. Anomaly screens on postings do not rewrite the control description. Keep journal entry anomaly detection in the testing lane, not in the narrative file.

Three failure modes show up in walkthroughs even when the prose looks polished.

Drafting a control that is not in the prior. The model completes a thin narrative by adding a secondary review, a system access recertification, or a detective report nobody runs. That is a new control. It will not match evidence, and it can create an untested assertion. If the change note does not add a control, the draft must not add one. Related process documentation, including an ESG disclosure draft, can mention overlapping activities. That overlap is not permission to insert a SOX key control.

Treating the draft as signed. A generated file in the GRC tool, a Word export, or a ticket comment is still a draft. External auditors and internal SOX testers ask who last signed, on what date, and whether the signer is the process owner. Until that signature exists, the prior signed narrative remains the operative description. Do not retire the prior version on the strength of a model output.

Inventing a frequency. Cadence (daily, weekly, monthly, quarterly, ad hoc) is a testable attribute. If the prior says weekly and the change note does not mention frequency, keep weekly. If neither source states frequency, leave the field empty. Continuous and real time are common inventions when a new system is named. They fail when the tester asks for the job schedule.

Other quiet inventions to strip on review: named reports that do not exist in SAP, Workday, or BlackLine for that entity; dual performers when the RACI still shows one; sample sizes; exception aging rules; ITGC language copied from another control.

The process owner remains accountable for accuracy. Sign-off means they have compared the draft to the process as it runs today, to the prior version, and to the change note. It does not mean they skimmed a fluent paragraph.

Practical sign-off checklist:

• Prior version ID and change-note ID appear on the draft.
• Every amended sentence has a cite. Unchanged sections are marked unchanged.
• Blank fields are still blank, or the owner filled them from operational knowledge and documented that fill as owner input, not as model output.
• No new control ID, no new activity, and no new frequency unless the change note states it.
• The signed copy is stored as the next narrative version in the SOX workspace. Unsigned drafts are labeled draft and are not the population for testing.

If the owner disagrees with the draft, they rewrite or reject. Do not iterate the model until it sounds right without re-loading the two sources. Sounding right is how invented frequencies and extra reviews enter the file.

AuditBoard, Workday, SAP, and BlackLine sit in the same class of systems of record: they store documentation or they run the process. None of them make the draft the signed narrative. The owner does.

When testing starts, testers pull evidence against the signed version, not against the generation log. Generation logs are useful for showing that a cite existed. They are not the control.