Audit fieldwork

An external audit in Keel runs on request lists. The auditor issues a list, your team answers each request with evidence, and the auditor tests what comes back. It all happens in your workspace, so the auditor reads evidence where it already lives.

How an auditor gets into the workspace, how long their access lasts, and how a firm shares the engagement across its staff are covered in Team & roles. This page is about the work once they are in.

The pages are under Internal audits: Information request lists, Auditor request list and Evidence requests. An auditor starts from Your audits, which lists every workspace where they hold the auditor role and what is still open in each.

Who can do what

Action	Owner, Admin	Member	Auditor
Issue, close or roll forward a request list	Yes	No	Yes
Raise a single request, comment on it, assign it, set its due date	Yes	Yes	Yes
Change what a request asks for	Yes	No	Yes
Attach evidence to a request and submit it	Yes	Yes	No
Accept a submitted request, or return it to the team	No	No	Yes
Accept or flag evidence on the auditor request list	No	No	Yes
Draw a sample, record results, raise a finding, record a test	Yes	No	Yes
Post a note the team cannot see	No	No	Yes
Write the management response to a finding	Yes	No	No
Download the tracker, the evidence binder and the fieldwork summary	Yes	Yes	Yes

Owners and admins can draw samples and record tests so they can test their own controls before the auditor arrives. Accepting and returning stay with the auditor.

For the team being audited

Request lists

In Information request lists, open Issue a request list and give it a title, the frameworks in scope, the audit period and a due date. Keel writes one request for every control mapped to those frameworks and checks each one against the evidence and policies the workspace already holds. Each request starts in one of three states:

• Matched: current evidence is already linked. The request goes straight to the auditor, and the team has nothing to do for it.
• Needs a current version: evidence is linked, but it is past its review date, was collected before the audit period, or the auditor flagged it.
• Gap: the control is not implemented yet, or nothing in Keel answers it.

Owners and admins are emailed when a list is issued. Every request on it takes the list’s due date.

The list page puts the team’s work first. Needs evidence shows gaps at the top, then items whose evidence is out of date. Below it are With the auditor and Accepted. To answer an item, open it, choose the evidence from the Choose evidence to attach menu, press Attach, and then press Submit to the auditor. Upload new evidence takes you to the evidence page if it is not in Keel yet. You can add a note for the auditor when you submit. A request with nothing attached cannot be submitted.

The auditor either accepts the request or returns it with a reason. A returned request comes back to the team to answer again.

One-off evidence requests

An auditor can also raise a one-off request from Evidence requests, written in their own words. If the text names a clause ref such as A.5.15 or CC6.1, or a control key, Keel files the request against that control. When it can only guess from keywords, it shows its suggestions on the request for someone to confirm. The team attaches evidence and submits, and the auditor accepts it or returns it with a reason.

To raise requests in bulk, use Raise evidence requests on the auditor request list, which creates one request per open item.

The auditor request list

Auditor request list builds the audit’s evidence requests from your controls and cuts them down to what is still missing. One control covers every clause it maps to, across every framework in scope. Each control lands in one of four groups:

• Still to request: nothing linked in Keel answers it, or the control is not implemented yet.
• Needs a current version: evidence is linked, but it is past its review date, predates the audit period, or the auditor flagged it.
• Already evidenced: implemented, with current evidence linked. The auditor inspects what is there instead of asking again.
• Marked not applicable: the auditor confirms the justification only.

Tick the frameworks in the audit and set the date the audit period starts. With no framework ticked, every control is listed. Raise evidence requests creates one request per open item, linked to its control and clauses, and skips a control that already has an open request. The list downloads as CSV, and Download evidence package exports your evidence.

What a request asks for

Each request has a What this request asks for section. It can name:

• Kind of evidence: point in time (a setting or state), sample (selected items), or full population (every item in the period).
• Source system, such as Okta or Jira.
• Report parameters: the filters and fields used, and how the report was run.
• Covers from and Covers to: the dates the evidence has to cover.

The auditor, an owner or an admin sets this. A member answering the request cannot change it. Each change is posted to the request’s conversation, so the team sees what the request now asks for. Once a request is accepted, what it asks for is fixed.

Evidence outside the requested dates

When a request has dates, Keel compares the collection date of each attached item with them and marks a mismatch as Outside the requested dates, with the reason. The rule depends on the kind of evidence:

• For point-in-time or sample evidence, the item must be dated inside the range.
• For a full population, the listing must have been pulled on or after the range ends. A listing pulled earlier may miss the end of the period, and Keel says so.

A request with no dates is never marked. The request list counts the requests affected under Evidence outside the dates, and the fieldwork summary reports them too. The mark is a warning for the people involved. It does not stop the team submitting.

Due-date reminders

Each weekday, Keel emails a reminder about requests that are waiting on the team (open, or returned by the auditor) and are due within the next few days or already overdue. The reminder goes to the person the request is assigned to. When nobody is assigned, it goes to every owner and admin, because an unowned overdue request is the one most likely to slip.

Each person gets one email per workspace that lists everything due, rather than one email per request. A request is reminded at most once every few days, and moving its due date makes it eligible for a fresh reminder. The request page shows when the last reminder was attempted.

Findings and the management response

When the auditor raises a finding from a sample exception, it is filed in the nonconformity register (see Nonconformity & CAPA) with its severity and a link back to the sampled item.

Open the finding to write the Management response: whether the team agrees, what it will do, and by when. Press Save response. Owners and admins can write it. The response is stored with the name of the person who saved it and the date. Until one is saved, the exceptions list on the request list says the finding has no management response yet, and the fieldwork summary prints “No management response recorded” in its place.

Downloads

The request list page has three downloads. Anyone in the workspace can use them, the auditor included.

• Download as CSV is the list as a tracker, one row per item.
• Download evidence binder (zip) holds a folder for each item with the files attached to it, plus README.txt, request-tracker.csv and binder-index.csv. The index lists every piece of attached evidence with its SHA-256 as recorded at upload, so the auditor can check that a file has not changed since. Links and attestations have no file, so the index carries their URL or description. An item with nothing attached gets a NO-FILES.txt note in its folder. If the binder is too large for one zip, Keel says so and points you to the evidence page instead.
• Fieldwork summary (print or save as PDF) opens a print-ready page. Use your browser’s Save as PDF to keep a copy.

The fieldwork summary sets out the list’s scope and audit period, then each finding with its severity, status, condition, management response, owner and due date. It also lists exceptions that were never raised as findings, and the state of every request: its evidence, its sample results and its test conclusion.

It is not an audit opinion. The summary says so on its face: it is a summary of fieldwork recorded in Keel, not an audit opinion or an attestation, and any conclusion belongs to the auditor who signs the report.

Rolling a list forward to the next period

Most audits recur. At the bottom of a request list, Roll forward to the next period issues a new list for the same frameworks. An auditor, owner or admin can do it. Keel suggests a title with the year moved on and an audit period one year later. Set the due date, then press Roll forward.

Every item is matched again against what the workspace holds now, the same way a new list would be. For a control that is in both lists, the auditor’s wording carries over, and so do the kind of evidence, the source system and the report parameters. The dates the evidence has to cover do not carry over. Each carried request’s conversation opens with a note saying how it ended last period. If last period’s sample had exceptions, the note asks you to check they were fixed. A control that has left scope is dropped.

The new list links back to last period’s, and owners and admins are emailed. Close list closes the old one. Its requests keep their state, and Reopen list brings it back.

For the auditor

Reviewing evidence

On Auditor request list, each linked piece of evidence has Review this item. Press Accept, or press Flag with a note saying what is wrong. Flagged evidence moves its control to Needs a current version, so the team is asked for a replacement. Anyone can reply with Comment.

Samples and the population source

On a request that is open or returned, open Draw a sample. Fill in:

• What the population is, for example “change tickets, Q1 to Q3”.
• Population, one item per line, pasted in.
• How often the control runs, which suggests a sample size, or a number in Sample size, which overrides it.
• Seed, which is random if you leave it blank.

The suggested sizes are a common starting point, not a standard. Your firm’s methodology decides. Keel draws the sample on the server and keeps the seed, the count and a SHA-256 fingerprint of the population. It does not keep the population itself. The same population, in the same order, with the same seed, redraws the same sample. The team is asked for evidence on each sampled item.

The same form records Where the population came from: Source system, Run on, Run by, Query or report and Completeness tie-out. Any part left blank is listed on the request as not recorded, with a warning that without it the population cannot be shown to be complete and accurate. The fieldwork summary lists the missing parts as well. To fill them in, draw again with the fields completed. Draw again keeps every earlier draw on record, and the newest draw is the one in force.

Pass or exception on each item

Each sampled item has a result: No exception or Exception. An exception needs a note saying what was wrong. Press Record, or Update to change a result you already recorded. An exception is posted to the request’s conversation.

Results belong to the sample in force. The request list gathers them in an Exceptions section across every request on the list. Each entry shows the sampled item, the note, and either the finding raised from it or “No finding raised.”

Raising a finding from an exception

On an item whose current result is an exception, choose a severity (Observation, Minor or Major) and press Raise finding. Keel files it in the nonconformity register, where the team records its management response. An item gets one finding. Pressing the button again raises nothing new.

Test procedure, walkthrough and conclusion

Under Test of this control, open Record the test:

• Methods: tick any of inquiry, observation, inspection and reperformance.
• Procedure: what was done, to what, and how many. This is required.
• Walkthrough notes (optional): who walked you through it, when, and what you saw.
• Conclusion: No exceptions noted, Exceptions noted or Not tested. When the request’s sample has exceptions, the conclusion starts at Exceptions noted.

Press Record test. The test is posted to the conversation, and the team can see it. To change it, use Record a revised test. That adds a new record, and the earlier one stays on file. The tracker, the binder and the fieldwork summary carry the conclusion in force.

Notes the client does not see

In a request’s conversation, tick Auditor only before you press Post. The note is hidden from the owner, admin and member roles, and an @mention in it only notifies other auditors. Auditor-only notes are marked as such in the thread you see.

AI help on a request

An auditor can press Assess this submission. The team sees Draft a reply to the auditor instead. Both use AI credits and work from evidence titles, dates and the request’s conversation, not from file contents. The auditor’s assessment reads auditor-only notes. The team’s draft never does. An owner or admin can cap auditors’ daily AI use in Settings → AI credits.

Next steps

• Team & roles: give an auditor or an audit firm access, and set when it ends.
• Nonconformity & CAPA: take a finding through root cause, corrective action and verification.
• Audits & management review: internal audits, which are a separate module with their own checklist and report.