Audit Findings: How to Write a Remediation Plan Auditors Accept

A remediation plan an auditor accepts has four elements for every finding: the root cause, classified as a design failure (the control was never adequate) or an operating failure (the control was adequate and was not followed), a named owner who is a person rather than a team, the specific corrective steps, and a target date. The classification is not paperwork. It decides what the fix is, who does it, how long it takes, and when the control can produce enough evidence to be tested again, so getting it wrong at the top of the page makes everything below it wrong.

This is the internal document, not the paragraph that appears in your report. Those are different artifacts with different audiences, and the difference matters enough that we come back to it below.

Key takeaways

• Every finding needs four things: a root cause classified as design or operating failure, a named individual owner, specific corrective steps, and a target date.
• The classification is the fork everything else hangs off. Ask one question: if everyone had done exactly what the documented process says, would this still have happened? Yes means design, no means operating.
• The corrective steps have to address the whole population, not the two items the auditor sampled. Fixing only the sampled items is the most common incomplete remediation there is.
• No standard sets a waiting period before re-testing. What governs it is the control's frequency, so prioritise low-frequency controls whose clock you cannot compress.
• The remediation plan and the management response are different documents for different audiences. Write the plan first and distil the response from it, never the reverse.

Design failure or operating failure

Take the same symptom and follow it down two paths.

The finding reads: two of twenty-five sampled terminations retained access beyond the stated one-business-day standard.

Path one, operating failure. The offboarding process is sound. It covers every system, it has an owner, it triggers from the HR system. In these two cases the ticket sat unactioned over a holiday weekend. The control was adequate. It was not followed. The fix is enforcement: an alert when an offboarding ticket ages past the SLA, a named backup for the owner, and a monthly check that nothing is ageing. Cheap, fast, and mostly about attention.

Path two, design failure. The offboarding process only covers systems behind single sign-on, and the two accounts in question were in a database that predates the identity provider and was never added to the checklist. Nobody failed to follow the control. The control never covered the thing that failed. Enforcement changes nothing here, because the process would run perfectly and still miss that database. The fix is structural: inventory every system that holds an account, put the database behind the identity provider or add it to the offboarding checklist with an owner, then re-run the check across all systems rather than the SSO ones.

The tell is a single question: if everyone had done exactly what the documented process says, would this still have happened? Yes means design. No means operating. Teams reach for "operating" because it sounds smaller and closes faster, and auditors have seen that instinct many times. A plan that classifies a design gap as an operating lapse gets read as either a misunderstanding of your own control or an attempt to shrink the finding, and both cost you more credibility than the finding did.

The four elements, and the weak version of each

Root cause. Strong: "the control's scope excluded systems outside SSO; the account inventory was last verified before the database was provisioned." Weak: "human error." Human error is a description of the symptom, and it points at no fix. If your root cause does not imply a specific corrective step, you have not found it yet.

Owner. Strong: a named individual with authority over the system and the process. Weak: "IT", "Engineering", "the compliance team". A team is not accountable to a date, and the first question in the follow-up meeting will be who exactly. If the honest answer is that nobody owns the process, that is itself the finding, and our piece on who owns compliance is about exactly that failure.

Corrective steps. Strong: enumerated, each independently verifiable, sequenced so dependencies are visible, and including the step that proves the fix worked across the whole population rather than for the two items that were sampled, with the evidence that step will have to produce named rather than assumed. Weak: "improve the offboarding process." Note the population point: fixing the two accounts the auditor found and not checking the other systems is the single most common incomplete remediation we see.

Date. Strong: a date that accounts for the operating history the control needs before it can be tested again, which is usually later than the date the fix ships. Weak: the end of the current quarter, chosen because it is the end of the current quarter.

When can the fix be re-tested?

There is no fixed waiting period, and anyone quoting you a standard number is quoting a habit. What actually governs it is sampling arithmetic, which we walk through in how audit sampling works: a control can only be tested once there are occurrences to sample from, and how many occurrences that takes depends on the control's frequency and the examiner's judgment.

Work it forward instead of guessing.

A control that runs on every deploy generates a population within days, so a fixed change-approval control can be re-tested almost immediately. A monthly access review generates one occurrence a month, so a fix that ships in March produces its first testable occurrence at the end of March and a meaningful run by the middle of the year. An annual control generates one occurrence a year, which is why an annual control that failed usually cannot be re-tested in the same period at all, and the finding stays in the report with the fix dated in it.

Two consequences follow. First, prioritise low-frequency controls in your remediation sequence, because they are the ones whose clock you cannot compress. Second, ask your examiner directly what they will need to see before they will consider the finding closed, and get the answer in writing. Firms differ, and the answer is cheap to obtain and expensive to assume.

The remediation plan is not the management response

Two documents, two audiences, and mixing them is a common error.

The remediation plan is internal. It is long, specific, owned, dated, and tracked to completion. It contains the root cause analysis, the dependencies, and the awkward truths about why the control was never adequate. Its audience is your own team and your examiner during fieldwork.

The management response is the paragraph that appears in the report itself, usually in the section reserved for other information provided by the entity. It is short, factual, and read by your customers' security teams for years. It acknowledges the finding, states the cause briefly, names any compensating control that operated during the period, and dates the fix. It does not argue with the auditor and it does not assert that the risk was low without evidence. We work through what a good one looks like, and what it costs you when it reads defensively, in can you fail a SOC 2 audit, which owns that conversation on this site.

Write the plan first. The response is a distillation of it. Doing it the other way round produces a response that promises something the plan cannot deliver, and next year's report is where that gets noticed.

The vocabulary, and where each word belongs

Severity language is framework-specific, and using the wrong dialect signals inexperience to the person reading your plan.

In a SOC 2 examination, a sampled item that failed is a deviation, and what appears in the report against the control is an exception. The opinion is unqualified, qualified, adverse, or disclaimed. There is no "minor" or "major" finding, and there is no pass mark.

In the SOX and financial reporting world, the ladder is control deficiency, then significant deficiency, then material weakness, and those terms carry defined consequences including disclosure obligations. Do not import them into a SOC 2 remediation plan; they mean something specific somewhere else.

In ISO 27001, an audit finding is a nonconformity, classified major or minor, and the standard's own corrective action requirements apply: identify the cause, evaluate whether similar nonconformities exist elsewhere, act, and review the effectiveness of what you did. That "does it exist elsewhere" step is a requirement in the ISO world and a very good habit in every other one.

What gets a plan rejected

From the plans we have watched go back for revision, five patterns account for most of it:

• The root cause is a symptom, so the corrective steps do not connect to it
• The owner is a department
• The steps fix the sampled items and never address the rest of the population
• The date ignores the operating history the control needs, so the plan promises a closure that arithmetic makes impossible
• The plan quietly redefines the control to be something the company is already doing, which is not remediation, it is rescoping, and it needs to be discussed openly with the examiner rather than slipped into a table

The fifth one is worth a sentence more. Sometimes redefining the control genuinely is the right answer: the original control was aspirational, nobody was ever going to run it weekly, and a monthly control that actually operates is better than a weekly one that does not. That is a legitimate conversation to have. It is not a legitimate thing to do silently in a remediation plan, because it changes what your report describes.

Where Top Floor fits

The useful outside contribution here is unglamorous: the classification argument, the completeness sweep across the rest of the population, and a realistic date. That is audit readiness and facilitation work, and when we run the programme itself the plan becomes a tracked artifact rather than a document that gets written once and revisited the week before next year's fieldwork.

If your findings are few and your owners are clear, you do not need help writing this. A shared document with four columns will do. The point at which outside help pays for itself is when the same finding appears two years running, because at that point the problem is not the control, it is that nobody owned the plan after the audit ended.

Frequently asked questions

What is the difference between a design failure and an operating failure?

Ask whether the failure would still have happened if everyone had followed the documented process exactly. If yes, the control's design is inadequate: it does not cover the case that failed, and the fix is structural. If no, the design was fine and the control was not followed, so the fix is enforcement, monitoring or training. The classification drives the corrective steps, the effort, and the timeline, which is why it belongs at the top of every finding rather than buried in the narrative.

How long after remediation can a control be re-tested?

Long enough for the fixed control to have operated often enough to sample, which depends entirely on its frequency. A control that runs on every deployment produces a testable population within days. A monthly control produces one occurrence a month. An annual control usually cannot be re-tested within the same period at all. No standard sets a waiting period, so ask your examiner what they need to see before they will consider the finding closed, and get the answer in writing rather than assuming a convention.

Should the remediation plan go in the report?

No, the plan is internal. What goes in the report is the management response: a short paragraph acknowledging the finding, stating the cause, naming any compensating control that operated during the period, and giving the date of the fix. The plan is the working document behind it, containing the root cause analysis, dependencies, owners and tracking. Write the plan first and distil the response from it, never the reverse.

Can we fix a finding before the report is issued?

You can fix the control, but you cannot remove the exception for the period it covers, because a Type II report describes what actually happened during the observation window. Remediation completed before issuance belongs in the management response with its date, and the examiner verifies it in the next cycle. The higher-value move is catching failures yourself mid-period: a control that failed in month two and ran cleanly for ten months reads very differently from one that was still broken when fieldwork started.