The Franken-Audit: When Good Evidence Becomes a Jumbled Mess

All audits start with the best of intentions, and at first glance, most of them get off on the right foot. The GRC export arrives with hundreds of files, HR has supplied the employee list, IT has pulled records from the identity provider, and engineering has added tickets from a separate system. Every team has responded to the request on time, and the audit tracker shows steady progress. It’s all going to plan … or so it seems.

And then the cracks start to appear when testing begins. You discover that the employee list and user export cover different dates, or a ticket refers to an application under an old name. You dig deeper and realize that two versions of a policy explain the same control differently, and nobody is sure which version applied during the review period. It dawns on you - you’ve gone from audit harmony to audit horror.

Welcome to the Franken-audit: an engagement stitched together from evidence that makes sense in its original setting but becomes confusing when assembled for testing. The consequences will last throughout the year, particularly for security teams coordinating audits across a large organization.

How individually useful evidence becomes confusing

While people think that their company is immune to this kind of snafu, it’s not such a far-fetched convern, and that’s why nearly two-thirds of organizations think that their audits are more efficient than they actually are. Take, as an example, an access review involving several business units: HR records establish who works for the company, and the identity provider shows accounts and their permissions. The review tickets document the decisions managers made, while other records show whether requested changes were completed. Each source contributes something useful, and together, they need to support a conclusion about how the control operated. Then suppose that the HR report was generated after an acquisition, but the account export covers only the original business. Of course some differences may be expected because the systems serve different populations, or others may reveal an omission. However, without an explanation of the boundaries and timing, the auditor has to reconstruct that context before evaluating the review.

That reconstruction becomes even harder when information arrives through separate channels. One owner explains a discrepancy in an email and then another uploads a replacement file without explaining what changed. The security team ends up maintaining the connection between artifacts, conversations and requests in its own working notes. It quickly becomes a witches' brew of disorganized data.

How clarification turns into rework

An auditor’s request to explain a discrepancy can quickly become another evidence collection exercise. A control owner generates a fresh export, someone reconciles it against the earlier submission, and the auditor reviews both to understand the difference. Meanwhile, other teams may be responding to similar requests using their own interpretations, leading to the same document getting submitted several times, or different documents being offered as proof of the same activity. As versions accumulate, it becomes difficult to distinguish a corrected submission from additional supporting information.

If you’re a security leader and this looks all too familiar, you’ll know that the cost extends far beyond the time spent uploading files, as senior staff become interpreters between the audit and the business, and then engineering, HR and IT are pulled back into work they believed they'd completed, making it harder to secure their attention for the next request. After all that, an auditor still needs to investigate discrepancies.

Establish the connections before collecting more files

Of course it doesn’t have to be like this, and the best place to start a smooth process is the audit request itself. You and your auditor need to agree at the outset on the systems and populations it covers, the relevant period, and the activity the evidence needs to demonstrate. For a recurring control, clarify whether the request concerns its design, its execution during the period, or both. Then identify which source supports each part of that explanation. In the access review example above, a current account list won't, on its own, establish that managers completed reviews earlier in the period. As such, review records may also need supporting evidence that the resulting actions were carried out.

Next, give the submission a short explanation of how its parts fit together, and note any expected differences between the sources, identify the applicable policy version, and explain when one file replaces another. The purpose of this work is to help the auditor understand the evidence without asking every control owner to reconstruct the story. While this may seem like a lot, these are all manageable decisions when made close to the activity. However, they're much harder when someone has to recover the context months later.

Use audit technology to reduce the stitching

Your choice of auditor can also have a significant impact on how smoothly the audit will run, and you should ask what systems and processes they have in place to eliminate potential Franken-aduits. Thoropass’ Smart Sort tool helps map evidence from existing GRC systems to relevant requests in our Audit Lifecycle Platform. Following that mapping, our First Pass reviews submissions for common readiness issues, including missing information and evidence outside the required period. These two tools combine to significantly reduce the amount of routine sorting and correction work, which both speeds up the overall audit, and reduces the likelihood of errors.

As we’re a GRC-agnostic solution, companies can work with Thoropass using their existing provider, while evidence moves into a workflow built for the audit. On top of this, if your organization uses its own AI agent like Claude, ChatGPT or Gemini, the Thoropass MCP server provides direct access to audit context, including scope and evidence requests. Authorized agents can use that context to help retrieve and prepare information from your connected systems, with human review remaining part of the process.

Combining all of this means that instead of constant back-and-forth chasing evidence, our experienced auditors then evaluate what the evidence supports, investigate inconsistencies and apply independent judgment. When a population is incomplete or two records disagree, understanding the business remains essential to reaching a sound conclusion.

Build an audit your team can follow

A useful test is to choose one control and follow its evidence from the original systems through to the audit request. Can someone explain what each artifact demonstrates, why the dates and populations differ, and which questions remain open? If that explanation depends on one person's memory, the process needs attention. Establishing clearer connections now can reduce the repeated requests that make an audit feel like a monster of your own creation.

Talk to Thoropass about connecting your existing evidence sources with an audit process supported by AI and experienced auditors.