An ISO 27001 audit finding is not a single thing. It can be a minor nonconformity that gets a corrective action plan and a handshake, or a major nonconformity that puts your certification on a clock. Confusing the two, or writing a root cause analysis that reads as “the analyst forgot,” is how teams end up in a suspension conversation with their certification body six months after what looked like a routine finding.
Definitions: major, minor, observation and opportunity for improvement
ISO/IEC 27001:2022 does not itself define the words “major” and “minor.” That classification comes from the auditing framework certification bodies use, built on ISO 19011 audit guidance and the accreditation rules their governing body enforces. In practice, every accredited certification body applies a version of the same four-tier scale.
| Category | What it means | Effect on certification | Typical response window |
|---|---|---|---|
| Major nonconformity | Absence or total breakdown of a required process, or a pattern of failures showing the ISMS is not operating as designed | Blocks certification or recertification until closed and verified | Usually 90 days, with evidence of correction and root cause, before the certificate can be issued or maintained |
| Minor nonconformity | An isolated failure to meet a clause or Annex A control requirement that does not indicate systemic breakdown | Does not block the certification decision; requires a documented action plan | Closed by the next surveillance audit, generally 6 to 12 months out |
| Observation | A weakness the auditor notices that has not yet caused a failure but could become one if left alone | No formal deadline, but often escalates to a minor NC if unaddressed at the next visit | No fixed window; tracked informally |
| Opportunity for improvement (OFI) | A suggestion for making an already-conforming process better | None; purely advisory | None |
The distinction that trips people up most is between “correction” and “corrective action.” A correction fixes the specific instance, patching the one server, retraining the one person. A corrective action changes the process so the same failure mode cannot recur. Auditors expect both, and they close on the second one, not the first.
What turns a single missed control into a major nonconformity
A single overdue patch on one server is rarely a major finding on its own. What escalates it is one of a few specific patterns auditors are trained to look for.
- Repeat findings. If last year’s surveillance audit raised the same clause or control and it recurs, most schemes automatically upgrade it to major, because it demonstrates the corrective action from the previous cycle did not work.
- Aggregation across sites or business units. Three minor findings against the same Annex A control in three different departments are not three isolated slips, they are evidence the control itself is not embedded, and get rolled into one major.
- Process absence rather than process failure. A late vulnerability scan is a minor slip in an otherwise working process. Two consecutive quarters with no scan at all means the process does not exist in practice, regardless of what the policy document says.
- Management system gaps. A skipped internal audit cycle, a risk assessment that has not been updated in over a year, or a management review that never happened all point at the ISMS’s own governance loop, which auditors treat as more serious than a technical control gap.
This is also why the mapping between your documented controls and the technical evidence that proves they operate matters as much as the controls themselves. Teams that keep an explicit link from each Annex A control to the system, log, or report that demonstrates it, through something like a compliance mapping view, catch the “process exists on paper but not in evidence” gap before an external auditor does.
The corrective action lifecycle: containment, root cause, action plan, verification
Containment or correction
This is the immediate fix: patch the box, revoke the credential, isolate the segment. Record the timestamp and the person who did it. This step alone never closes a nonconformity, but its absence from the record makes auditors suspicious that nothing happened until the audit forced it.
Root cause analysis
Identify the mechanism that allowed the failure, not the person who triggered it. This is the step most CA reports fail on, and it gets its own section below.
Action plan
Every action plan needs four things before it is submitted: a named owner, a target date, the specific process or control change being made, and the evidence type that will prove it worked. “We will improve monitoring” is not an action plan. “We will add an automated alert when a critical-severity finding exceeds its SLA, owned by the SOC lead, live by the 15th” is.
Verification
Verification checks that the fix worked over time, not that the ticket was closed. For a major nonconformity this is usually done on-site or via a documented remote review by the certification body before the certificate is released. For a minor, your own internal audit function typically verifies first, and the certification body samples it at the next surveillance visit.
Writing a root cause analysis that auditors accept instead of “human error”
“Human error” is rejected almost every time because it does not explain why the system allowed that error to produce the consequence it did. A competent auditor’s next question is always “what would stop this from happening again with a different person,” and “human error” has no answer to that.
Use a structured method and show your work, not just the conclusion. The 5 Whys is the most commonly accepted format because it is easy for an auditor to audit:
- Why was the critical vulnerability still open after 45 days? The remediation ticket sat unassigned in the queue.
- Why did it sit unassigned? No one was notified when it crossed the 14-day SLA.
- Why was there no notification? The ticketing system had no automated SLA-breach escalation configured.
- Why was escalation not configured? The SLA policy was written after the ticketing workflow was built, and the two were never reconciled.
- Why was that reconciliation never checked? There is no periodic review step that verifies policy and tooling stay in sync.
The root cause here is a missing reconciliation and escalation step, not the individual who missed the ticket. Your CA report should include: the nonconformity statement with the exact clause or Annex A control cited, the evidence the auditor found, the correction applied and its date, the root cause method used and its full chain, the corrective action with owner and date, and the verification evidence with the date it was reviewed. Certification bodies reject vague reports on resubmission almost as often as they reject “human error” the first time, so completeness on the first pass saves a full review cycle.
Closure deadlines and proving effectiveness at the next audit
Most certification schemes give 90 days to close a major nonconformity with documented correction, root cause and a credible action plan before the certification decision is finalized or the existing certificate is suspended. Minor nonconformities do not block a decision, but they carry an unwritten expectation: show up to the next surveillance audit, typically 6 to 12 months later, with the action implemented and evidence that it held for more than the week before the auditor arrived.
This is where teams get caught out. An auditor re-testing a previously closed finding does not want a single clean sample from last Tuesday. They want to see the control operating across the full period since closure, ideally with a continuous log rather than a point-in-time screenshot. If your corrective action was “add SLA-breach escalation,” the auditor will ask for every escalation triggered since implementation, not just the one that happens to look good.
Worked example: a missed vulnerability remediation deadline
An organization’s information security policy sets a 14-day remediation SLA for critical-severity findings on internet-facing assets. During the Stage 2 audit, the auditor samples the vulnerability register and finds a critical CVE on a customer portal server that stayed open for 45 days.
Classification depends on what the rest of the sample shows. If this is the only instance out of dozens of otherwise on-time remediations, it is likely minor: an isolated slip in an otherwise functioning process. If the sample turns up three more assets with similar overruns, or the same finding appeared unresolved in last year’s audit, it becomes major, because it now points at a broken escalation mechanism rather than one missed ticket.
Containment: the finding is patched immediately, and the timestamp is logged. Root cause, following the chain above: the SLA clock started at ticket creation rather than at vulnerability discovery, and no automated alert fired when the SLA was breached. Corrective action: remediation timestamps are now tied to the scanner’s discovery date, and an automated escalation notifies the asset owner and their manager when a critical finding crosses 10 days without a remediation ticket in progress.
The verification evidence is the part auditors scrutinize hardest, because it is the easiest part to fake with a single cherry-picked example. Platforms that automate this phase, such as SITEY, close the loop by re-testing the specific finding once a ticket is marked remediated and writing the retest result and timestamp back against the original finding ID, so the discovery date, the remediation date, and the retest confirmation all sit in one traceable record rather than three separate exports somebody has to reconcile by hand for the auditor. Whether or not remediation is automated, the underlying requirement is the same: the evidence chain from discovery through the full lifecycle of the finding, through the patch management step, to a documented retest and closure record, needs to exist without manual reconstruction, because that is exactly what the next surveillance audit will ask to see.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.