by Quick answer: Take a breath, read the findings carefully, group them by risk, fix the high-impact ones first, document everything, and agree a retest date with the auditor. A failed audit is useful information, and most findings come from a small number of root causes.
First, understand what “failed” means
Different audits fail in different ways. A SOC 2 or ISO 27001 audit usually produces exceptions or nonconformities rather than a simple pass or fail. A customer security review might end with “not approved yet”. A penetration test produces findings, not a verdict. Start by asking: which findings blocked the outcome, and which are minor?
Step 1: Read the report with the auditor
Ask for a walkthrough. Make sure you understand each finding, what evidence the auditor expected and what would close it. Misunderstandings about evidence are behind many findings that turn out to be quick fixes.
Step 2: Triage by risk and effort
List every finding with three columns: severity, effort to fix, and owner. Then sort into:
- Fix now: high severity, especially anything that exposes data or allows account takeover.
- Quick wins: low effort, easy to close, such as missing policies or unsigned approvals.
- Plan: larger projects like network segmentation or tooling, which need budget and time.
- Accept or challenge: items you can formally accept as risk, or that you believe are incorrect.
Step 3: Find the root causes
Ten findings are often two problems. Common patterns:
- No named owner for security, so tasks fall through the cracks
- Policies written but never operated, so there is no evidence
- Access reviews, patching or backups done informally and unrecorded
- Shadow IT and unmanaged assets
Step 4: Build a remediation plan
- Assign each item an owner and a date.
- Track progress in one place, visible to leadership.
- Capture evidence as you go: screenshots, tickets, logs, signed approvals.
- Review weekly until the high-severity items are closed.
Step 5: Communicate
If a customer or regulator is waiting, tell them proactively what you found and when you will fix it. A credible remediation plan with dates is often more reassuring than a clean report with no explanation.
Step 6: Retest and prevent a repeat
Agree a retest or follow-up window with the auditor. Then make the fixes stick: schedule recurring tasks for access reviews, vulnerability scans, training and policy reviews, and consider a readiness assessment before the next audit.
What “failing” looks like in different audit types
| Audit or review | What a bad result looks like | What usually happens next |
|---|---|---|
| SOC 2 | Qualified opinion or exceptions in control testing | Fix the control, improve evidence, often re-test in the next period |
| ISO 27001 | Major or minor nonconformities | Corrective action plan with deadlines; certification may be delayed |
| PCI DSS | Not in place or non-compliant requirements | Remediation and re-validation with the assessor or acquirer |
| HIPAA risk analysis or OCR audit | Gaps in required safeguards | Remediation plan; regulators may require corrective action |
| Customer security review | Not approved, conditional approval | Provide evidence or a remediation timeline to unblock the deal |
| Penetration test | Critical or high findings | Fix and retest; share the retest letter |
A simple triage matrix
Put every finding on two axes: how risky it is and how hard it is to fix. This turns an overwhelming report into an ordered list.
| Low effort | High effort | |
|---|---|---|
| High risk | Do this week: enable MFA, close exposed services, patch critical systems | Start now with an interim control and a funded project plan |
| Low risk | Batch as quick wins: update policies, collect missing approvals | Schedule, or formally accept the risk with sign-off |
What to put in a remediation plan
- Finding reference exactly as the auditor wrote it
- Root cause in a sentence, not just the symptom
- Corrective action that will close the finding
- Owner by name and role
- Target date and a milestone for progress
- Evidence to be produced, such as a screenshot, ticket or log export
- Status and last update date
How to talk to customers and leadership
Keep the message factual and time-bound. For a customer waiting on your security review, a short note often works best: state that an independent review identified specific improvements, summarise the actions already completed, give dates for the rest and offer a call with your security lead. Avoid minimising the issue or overpromising. For leadership, translate findings into business impact: deals at risk, regulatory exposure, cost and the people required.
Evidence habits that prevent repeat findings
- Capture evidence when the control runs, not months later
- Name files consistently with date, system and owner
- Use tickets for recurring tasks such as access reviews so the record builds itself
- Keep a single evidence register mapped to controls
- Do an internal “mock audit” a month before the real one
Common findings by framework, and the usual fix
- SOC 2: access reviews not performed or not evidenced; new hires missing background checks or training records; change tickets without approvals; no evidence of backup restore tests. The fix is almost always a recurring task with an owner and a ticket.
- ISO 27001: risk assessment not updated; Statement of Applicability out of date; no internal audit or management review minutes; supplier assessments missing. The fix is a calendar of management-system activities.
- PCI DSS: cardholder data found outside the defined scope; weak or missing MFA for administrative access; unpatched systems; missing quarterly scans. The fix is scope reduction and discipline around scanning and patching.
- HIPAA: risk analysis incomplete or outdated; no business associate agreements for some vendors; missing audit logging; unencrypted devices. The fix begins with a current, enterprise-wide risk analysis.
Who needs to be in the room
Audit remediation is rarely a purely technical task. Make sure the following people are involved from the first meeting after the report arrives:
- Executive sponsor: removes blockers, approves budget and signs risk acceptances.
- Security or compliance lead: owns the plan, evidence and communication with the auditor.
- Engineering and IT leads: own technical fixes and the reliability of recurring tasks.
- HR: owns onboarding, training, background checks and offboarding evidence.
- Legal or privacy counsel: advises on contractual and regulatory impact and customer communications.
- Sales or customer success: manages affected customer relationships using approved messaging.
A 30-60-90 day plan to a clean retest
Days 1–30: Stabilise
Hold the walkthrough with the auditor, finish triage, close the high-risk and quick-win findings, appoint owners and agree dates for everything else. Start a weekly status meeting and a single tracker.
Days 31–60: Build repeatability
Tackle the medium-effort items and convert one-off fixes into recurring controls: calendar reminders, ticket templates and automation for evidence collection. Update policies so they describe what you really do.
Days 61–90: Prove it works
Run an internal mock audit, sample your own evidence, fix any gaps and confirm the retest or re-audit date with the auditor. Report results to leadership.
Mistakes that cause a second failure
- Fixing the symptom, such as producing one missing screenshot, without fixing the process that created the gap
- Writing policies that promise more than the team actually does
- Assigning findings to a team without agreeing a date
- Waiting until the week before the retest to collect evidence
- Making large unplanned changes close to the audit that create new findings
- Treating compliance as one person’s job instead of a shared operating rhythm
Frequently Asked Questions
How long do we have to fix things?
It depends on the framework and auditor. Many allow a remediation window, and SOC 2 audit periods can sometimes be re-run. Ask early.
Can we dispute a finding?
Yes, if you have evidence that the control exists. Provide documentation rather than argument.
Should we change auditors?
Rarely. A different auditor will usually find the same gaps. Fix the controls instead.
How soon can we re-audit after failing?
It depends on the framework and auditor. A re-test of specific controls can be quick, while a full report period such as SOC 2 Type II may require a new observation window. Ask your auditor for the options early.
Does a failed audit mean we must tell customers?
Not necessarily, but if customers rely on the report or certificate, or if contracts require notice, you should communicate promptly with a remediation plan. Check your contracts.
What is the most common reason for audit exceptions?
Controls that exist on paper but are not performed consistently or documented, such as access reviews, onboarding and offboarding checks, and change approvals.
Should we hire a consultant after a failed audit?
If you lack internal capacity or experience with the framework, a short engagement to triage findings, build the plan and run a mock audit is often faster and cheaper than a second failed attempt.
Can we accept some risks instead of fixing them?
Often yes, when the risk is low or the cost of remediation is out of proportion. A formal, signed risk acceptance with a review date is usually acceptable evidence, but auditors may still note it, so check requirements for your framework.
Need a clear path back to a pass?
We’ll triage your findings, build a remediation plan and prepare you for the retest. Explore our security assessment and audit services →
