Step 1: List the audits and the questions each will ask
A financial audit asks who authorised each ledger entry and whether an automated process could post alone. A security review asks what access each automated actor held, how it was scoped, and how it could be revoked. A data protection audit asks what personal data each actor processed, retained, and on what basis, and how subject rights were honoured. Each maps to a Digital FTE mechanism on ftes.ai: the approval gate and the autonomy ladder, the scoped connections and the connection review, the Brand Brain's contents and the retention of drafts. Write the list of audits with their questions and the mechanism that answers each.
The audit trail piece in the library describes what the trail records; this playbook is about producing it for someone else.
Step 2: Export the audit trail per role for the period
For each Digital FTE, export the audit trail for the audit period from the workspace: every proposal, approval with the approver's name and time, send-back with its reason, escalation with its receiver, autonomous action by a promoted class with the class and bounds, memory change with provenance, connection change, and plan change. For a financial audit, the finance role's export answers the authorisation question for every entry; the entries a promoted class posted alone are listed with the promotion note that allowed them. Keep the exports with the period's other working papers.
An auditor who can trace one entry end to end in the export usually stops sampling early.
- Per role, per period, from the workspace
- Approvals with names; autonomous actions with class and bounds
- Memory, connection, and plan changes included
Step 3: Prepare the remit and promotion history
The auditor's second question is what the role could do alone and who decided. The remit in Setup has a version history: the three lists at each date, the always-escalate list's growth, and the never-automated list, which nobody can change. The monthly review notes record each promotion under the Promotion Standard with the bounds and the step-back trigger, and each step-back with its reason. Together they show that every autonomous action was inside a class a named manager promoted from a record, within written bounds, and that money, people, and prices were never eligible. Print or export them for the period.
The framework piece on the Promotion Standard is the policy the notes follow, and can be attached as such.
Step 4: Run the connection review and confirm scopes at the tools
The access question is answered by the quarterly connection review, run for the audit if the last one is not recent: for every connection each role holds, confirm at the tool's own admin that the account is dedicated, that its permissions are the narrowest the remit needs, and that a forbidden action is refused; record the confirmation with the reviewer's name and the date. Add the disconnection path: show one disconnection in the trail, or perform one on a test connection. The security lead's persona piece lists the twelve checks a reviewer performs, and the audit is the moment to have performed them recently.
Include the answer to the isolation question in writing: how a request for another organization's or property's record behaves.
Step 5: Export the memory and state what was retained
For a data protection audit, export each role's Brand Brain and show its contents: business facts, voice, policies, and preferences, each with provenance, and no personal data about individuals by design. State the retention of drafts and proposals, which follows the underlying activity, and how subject rights requests reach the FTE's processing through the connected systems it works from. Attach the data processing terms and the sub-processor list including the model provider, and the written statement that the platform does not train on customer data. The GDPR guide in the library lists the questions the data protection lead expects.
A memory with provenance on every item is an unusual thing to be able to show an auditor, and it shortens the conversation.
Step 6: Prepare the incident log with recorded fixes
The auditor reads most closely what went wrong. Prepare the incident log for the period: each incident, its detection, the four-step response the manager ran, the remit or memory change recorded, and the step-back if a promoted class was involved. Include near-misses the send-back reasons caught: a stale article, a changed fee schedule, an escalation that arrived without its summary. An incident log with recorded fixes is evidence of a control environment that works; an empty one is evidence of a log nobody kept. The incident playbook in the library describes the four steps.
The Never list's growth after incidents is itself evidence the auditor will want to see.
What does done look like?
A folder per audit with: the list of questions and the mechanism answering each; audit trail exports per role for the period; remit version histories and monthly review notes with promotion and step-back records; the connection review with confirmations at the tools, names, dates, and the written isolation answer; Brand Brain exports with the retention statement, processing terms, and sub-processor list; and the incident log with recorded fixes. The auditor traces one entry, one promotion, one connection, and one incident end to end, and the rest is sampling.
The whitepaper on trust architecture describes the layers the folder documents.