agentleFS
samsational-codesamsational-code/business-skills/audit-request-binder/SKILL.md

audit-request-binder

Skill0 starsChanged 2 months agoMITView on GitHub

Turn an auditor's, regulator's, certifier's, or enterprise customer's document request list into an organized, indexed production — mapping each request item to responsive organizational records, surfacing the gaps where a policy exists but evidence it was operated does not, drafting narrative responses to auditor interview questions from the organization's actual policies, and producing a prioritized remediation list. Also runs as a mock audit against the standard request categories for the audit type before any request arrives. For compliance leads, controllers, security and IT managers, operations heads, program managers, and anyone who owns an audit response — SOC 2, ISO certification, internal audit, tax audit, regulatory exam, customer security audit, grant or funder audit, quality audit. Trigger on phrases like "we got an audit request," "document request list," "prep for the audit," "run a mock audit," "map this request list," "what are we missing for the audit," "evidence request," "auditor interview questions," "finding remediation," or when a user uploads an audit request list, policy manual, control matrix, or prior audit report. Do NOT use for screening marketing material for claim-substantiation problems — use the marketing-claims-prescreen skill. Do NOT use for evaluating a third party's completed questionnaire — use the questionnaire-red-flag-scanner skill. Not legal advice; involve counsel where the audit has legal or regulatory consequences.

The file

Files
SKILL.md

Audit Request Binder

Turn a document request list into an indexed production and an honest gap list. Every request item mapped to the records that answer it, every gap ranked by how much trouble it is, narrative responses drafted from the organization's real policies, and a remediation list you can work. Run it against a live request list, or against the standard request categories for the audit type as a mock audit while there is still time to fix what it finds.

Why this skill exists

The two weeks after an audit request arrives are the worst two weeks in the response owner's year, and the quality of the initial production sets the tone for everything that follows. A production that arrives organized, indexed, and internally consistent reads as an organization with a functioning control environment. One assembled in a scramble — inconsistent date ranges, documents that contradict each other, a policy produced with no evidence it was ever followed — invites the auditor to look harder.

The gap that causes real problems is specific and predictable: a written policy with no record of operation. Organizations rarely lack policies. They lack the log, the ticket history, the sign-off, the training record, the review memo, or the meeting minutes showing the policy was actually run. That gap is findable months in advance, and it is almost never found, because nobody sits down and maps records to requirements until the request forces it.

Inputs

Required (one of):

  • The audit document request list (from an external auditor, certifier, regulator, tax authority, funder, or enterprise customer), or
  • A request that the skill build a mock request list from the standard request categories for the audit type and the organization's business model

Required in either case:

  • The organization's relevant policies and procedures — policy manual, control matrix, security policies, accounting policies, employee handbook, quality manual, or whatever governs the area under audit
  • An inventory of records the organization holds — what exists, where, who owns it, and for what date range. A rough list is fine; precision comes later.

Optional but high-value:

  • The most recent internal review, self-assessment, or management testing of the area, and any prior audit reports, findings, or management letters
  • Public-facing or filed descriptions of the organization that the production must agree with — website, customer-facing security documentation, prior filings, registration statements, grant applications, contract representations
  • The specific interview questions the auditors have flagged, or the topics the request letter emphasizes
  • Organization profile: size, headcount, locations, systems in scope, customer types, key vendors, whether the organization has been through this audit type before

Missing-input behavior: The record inventory is the input people most often skip, and the output is nearly worthless without it — a mapping table with no records to map to is just the request list retyped. Ask once for the inventory, and accept an approximate one. If the policy documents are unavailable, the narrative responses cannot be drafted from organizational policy; produce the mapping and gap analysis, and say clearly that the narrative section was skipped rather than writing generic answers that misdescribe the organization.

How it works

  1. Parse the request list into discrete items. Audit requests bundle several asks into one numbered paragraph. Split them — each distinct document type and date range becomes its own row, retaining the original item number for the response index.
  2. Map each item to responsive records from the inventory: document name, owner or system of record, format, and the date range actually available versus the date range requested. A partial date range is a finding, not a match.
  3. Classify every item as fully responsive, partially responsive, no responsive record, or not applicable to the organization — and for "not applicable," draft the one-sentence explanation the response will need, because an unexplained blank reads as a refusal.
  4. Run the policy-versus-evidence test on every mapped item. For each area, ask separately: is there a written policy or control? Is there evidence the policy was operated during the review period? These are different questions and the second one fails far more often. Flag every case of policy-without-operating-evidence as a distinct gap type.
  5. Check internal consistency across the production. Records produced together must agree with each other and with anything the organization has represented externally: headcount, revenue or budget figures, system inventories, vendor names, org charts, process descriptions, scope statements, dates of policy adoption. Contradictions between produced documents are among the most damaging findings, and they are entirely preventable.
  6. Draft narrative responses to interview-style questions, grounded strictly in the organization's actual policies and quoting the policy where relevant. Where practice differs from the written policy, say so in the internal output — never paper over it in a response.
  7. Rank the gaps by severity: likelihood of becoming a finding, and how bad that finding would be (qualified opinion, failed certification, penalty, lost customer, clawed-back grant, repeat finding).
  8. Build the remediation list, separating what can be genuinely fixed before production from what must be disclosed and remediated going forward — and be explicit about that distinction.

Output format

# [Organization] — Audit Preparation Binder
Audit type: [SOC 2 / ISO / internal audit / tax / regulatory / customer security / grant / quality / other]
Mode: [live request list / mock audit vs. standard categories]
Request list: [source, date] | Review period: [dates] | Prepared: [date]
Records inventory as of: [date]

## Readiness summary
[4–6 sentences: how much of the request the organization can satisfy today,
the number of gaps by severity, and the 2–3 items that need attention first.]

Items: [N] fully responsive / [N] partial / [N] no record / [N] N/A
Gaps: [N] HIGH / [N] MEDIUM / [N] LOW

## Request mapping
| Item # | Request (short) | Responsive record(s) | Owner / system | Period held vs. requested | Status |
|---|---|---|---|---|---|

## Policy-vs-evidence gaps
The findings that matter most. For each:
### G1. [Area]
- **Policy / control:** [exists / absent] — [document §, quoted if useful]
- **Evidence of operation:** [what exists, or what is missing]
- **Request items affected:** [#s]
- **Why an auditor would care:** [1–2 sentences, tied to the requirement or control objective]
- **Severity:** HIGH / MEDIUM / LOW
- **Remediable before production?** [yes — how / no — why]

## Internal consistency check
| Fact | Source A (doc, §) | Source B (doc, §) | Consistent? |
|---|---|---|---|
[Headcount, financial figures, system and vendor lists, scope statements,
process descriptions, policy adoption dates — each cross-checked against
external representations, not only across produced documents.]

## Drafted narrative responses
### [Interview question]
[Response drafted from organizational policy, with document citations. Any
place the draft relies on a practice not documented in policy is marked
**[UNSUPPORTED BY POLICY — confirm before use]**.]

## Production index
| Reference / file | Document | Item # responded to | Date range | Pages |
|---|---|---|---|---|

## Remediation list
| # | Gap | Action | Owner | Fix before production? | Priority |
|---|---|---|---|---|---|

## For counsel or the audit committee
Items where privilege, disclosure obligations, contractual representations,
or the scope of the response need a lawyer's or governance body's judgment
before anything goes out.

Standard request categories

Use as the checklist when building a mock request list, and as a completeness test against a live one. Scope to the organization's actual business and to the audit type — a company with no physical inventory should not be producing cycle-count records, but should be able to explain why not. Not every category applies to every audit; pick the ones the audit type actually tests.

  • Organizational documents, ownership, legal entities, affiliates, and org chart
  • Policies and procedures for the area under audit, and the internal review or management testing that supports them — including the evidence that testing was actually performed
  • Access control: user access lists, provisioning and deprovisioning records, periodic access reviews, privileged access logs
  • Change management: change tickets, approvals, testing evidence, deployment logs, emergency change records
  • Security program: risk assessments, vulnerability scans and remediation tickets, incident log and post-incident reviews, security awareness training records
  • Vendor and third-party management: vendor inventory, due diligence files, contracts with security or data terms, periodic vendor reviews
  • Business continuity and disaster recovery plans, with test records
  • Financial records: general ledger, reconciliations, journal entry support, revenue recognition documentation, expense approvals, fixed asset registers
  • Tax: returns as filed, supporting workpapers, positions taken and their support, correspondence with tax authorities
  • Grant or program funds: award agreements, budgets vs. actuals, expenditure support, time and effort records, subrecipient monitoring, required reports as submitted
  • Customer and contract records: agreements, amendments, side letters, service-level commitments, complaints log
  • Human resources: hiring and background check records, onboarding and offboarding checklists, training completion, code of conduct acknowledgments
  • Data handling: data inventory, retention schedule and evidence of enforcement, privacy notices, data subject request log, breach notification records
  • Quality and operations: process controls, inspection and test records, nonconformance and corrective action logs, calibration records
  • Conflicts of interest: disclosure forms, related-party transactions, approvals
  • Governance: board and committee minutes, charters, evidence of oversight
  • Regulatory filings and evidence of timely submission, where applicable
  • Prior audit findings and evidence that each was remediated

Guardrails

  • Never draft a record to fill a gap. If evidence of operation does not exist for the review period, the answer is that it does not exist. Creating a document now and presenting it as contemporaneous is a far more serious problem than the original gap. Every remediation item is explicitly labeled as prospective or as a genuine pre-production fix (e.g. locating a record that exists but was not inventoried).
  • Never backdate, and never describe a remediation as if it predates the request.
  • Ground narrative responses in the organization's policy, not in best practice. If the organization's policy is weaker than what an auditor would like, the draft says what the policy is. Aspirational descriptions of a program the organization does not run are the fastest route to a misrepresentation finding.
  • Flag every place practice diverges from the written policy in the internal output. That divergence is a real finding and it belongs in remediation, not in a smoothed-over response.
  • This is not legal advice. Audit responses can have legal, regulatory, and contractual consequences, involve privilege questions, and can create disclosure obligations. Counsel or the responsible governance body reviews before anything is produced — say so in the output.
  • Do not assert requirements without grounding. Where a standard, regulation, or contract clause is cited, cite it accurately from the supplied materials; where a practice is convention rather than requirement, label it convention. Standards and audit priorities change — verify current requirements rather than relying on recall.
  • Confidentiality and privilege: audit materials, policy documents, and the gap analysis are sensitive and potentially privileged. Assume an organization-approved AI environment. The gap analysis in particular should be handled with counsel's guidance on privilege before it circulates.

Quality checks

  • Every request item split to its distinct asks and assigned a status
  • Date ranges compared — held vs. requested — not just presence checked
  • "Not applicable" items each carry a drafted explanation
  • Policy and evidence-of-operation assessed as two separate questions for every area
  • Consistency check run against external representations, not only across produced documents
  • Narrative responses cite the policy, with unsupported claims explicitly marked
  • No remediation item involves creating a document that implies it existed earlier
  • Remediation split into pre-production vs. prospective, with the distinction stated
  • Counsel / governance items separated out
  • Production index is usable by someone who did not build it

Example prompts

"Our SOC 2 Type II auditor sent the evidence request list Friday — attached, observation period is the last 12 months. Our security policies, control matrix, and a rough inventory of what we've got are also attached. Map it, tell me where we're exposed, and draft responses to the interview questions in items 14–18."

"No audit pending. Build a mock request list for an ISO 9001 surveillance audit at a 60-person contract manufacturer with two sites, run our quality manual and records inventory against it, and tell me what we'd fail on today."

"Our largest enterprise customer is exercising its contractual right to audit our data handling. Their request list, our privacy and retention policies, and our vendor list are attached. Build the binder and flag anything where what we told them in the security questionnaire doesn't match what we can evidence."

"Prior internal audit report attached along with our remediation memo. Build the binder for this year's audit and specifically show me whether we can evidence that each prior finding was actually fixed."

"Federal grant closeout audit — award agreement, our budget-vs-actual, and the auditor's request list are attached. Map it and tell me where our time-and-effort records don't cover the full period."

Works well with

Run marketing-claims-prescreen over any marketing or customer-facing materials being produced, since substantiation of external claims is a common request category and a common finding. Use meeting-minutes-generator to build the defensible governance and committee records this skill will look for. Use questionnaire-red-flag-scanner when the shoe is on the other foot and the organization is the one evaluating a vendor's responses.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.