Evaluating Audit Findings and Deriving Actions

TL;DR

Findings are classified into four categories: positive finding, observation, minor nonconformity, and major nonconformity.
The distinction between minor and major NC depends not on the severity of the individual finding but on whether a systemic failure exists that jeopardizes the effectiveness of the ISMS.
Every nonconformity requires a root cause analysis. If you only fix the symptom, you will encounter the same finding at the next audit.
Corrective actions must eliminate the cause, not just the symptom. A good action is specific, time-bound, assigned to a named person, and verifiable in its effectiveness.
The effectiveness review is mandatory per ISO 27001, Chapter 10.1. Only when it is demonstrated that the action works may a nonconformity be marked as closed.

Classifying Findings Correctly

Every audit produces findings. Some confirm that a process is working as intended. Others uncover weaknesses that must be addressed. The art lies in placing each finding into the right category, because the category determines what happens next.

An assessment that is too strict frustrates the organization and undermines the acceptance of the audit process. An assessment that is too lenient leaves real problems unsolved and endangers the ISMS. The correct classification requires experience, knowledge of the standard, and good judgment. And it requires clear criteria that auditors can rely on.

The Four Finding Types in Detail

Positive Findings

Positive findings are often forgotten but are an important component of a balanced audit report. They document areas that are working particularly well and give the responsible persons recognition for good work.

Positive findings have a second benefit: they show management that investments in information security are having an effect. If every audit only lists problems, the impression arises that nothing works. That can lead to declining motivation or to management questioning the entire ISMS.

Example: "The patch management for server systems is exemplary. All reviewed critical patches were applied within the defined 14-day window. Documentation is complete, and responsibilities are clearly assigned."

Observation

An observation describes a condition that is currently still conforming but poses a risk of future nonconformity. Or it identifies improvement potential without there being a concrete standard violation.

Observations are the early-warning system of the audit. They give the organization the opportunity to act proactively before a weakness turns into a deviation. They do not require a formal corrective action but should be documented and re-examined at the next audit.

Typical observations:

A process works but is person-dependent. If the responsible person is unavailable, there is no backup arrangement, and the documentation is not sufficient for someone else to take over.
The access control policy was reviewed on schedule, but the review was purely formal (date updated, content not examined).
The risk register is maintained, but risk assessments are based on individual estimates rather than a structured methodology.
Training records exist, but there is no verification of whether the content was actually understood.

Example formulation: "The quarterly review of access rights is conducted and documented. However, the review is limited to Active Directory accounts and does not cover access rights in the four SaaS applications (Salesforce, Jira, Confluence, Slack) that also contain business-critical data. It is recommended to extend the scope of the access review to all relevant systems."

Minor Nonconformity

A minor nonconformity exists when a standard requirement is not fully met, but the deviation is isolated and does not endanger the overall effectiveness of the ISMS. It is a point-specific weakness, not a systemic failure.

Characteristics of a minor NC:

A single requirement of the standard is partially not met.
The process fundamentally exists and works but is not consistently followed.
The deviation affects a limited area (one department, one system, one process step).
There is evidence that the process is generally understood and mostly applied.
The deviation has no immediate serious impact on information security.

Examples of minor NCs:

"For three of ten reviewed access changes in the period Q1/2026, the documented approval by the responsible manager is missing, as required by the access control policy (ACR-001, Section 4.2). The changes themselves were factually correct and traceable."

"The information security policy (IS-POL-001) was last reviewed on January 15, 2024. The policy requires an annual review. The review deadline has therefore been exceeded by 14 months. The content of the policy remains factually accurate."

"For employee X, who left the company on November 30, 2025, active access rights in the ERP system were still in place at the time of the audit (March 10, 2026). The offboarding process (HR-PRO-003) requires deactivation within two business days."

Major Nonconformity

A major nonconformity means that a standard requirement is completely unfulfilled, or that multiple related weaknesses point to a systemic problem that endangers the effectiveness of the ISMS as a whole.

Major NCs are the red card of the audit. In a certification context, an open major NC means the certificate will not be issued or will be suspended until the deviation is remediated. In an internal audit, they require immediate management attention and prioritized treatment.

Characteristics of a major NC:

A standard requirement is completely not met (e.g., no risk treatment plan exists).
An entire standard chapter or a significant area of the ISMS is affected.
Multiple related minor NCs indicate a systemic problem (e.g., missing document control in all reviewed areas).
The deviation endangers the ISMS's ability to fulfill its purpose.
There is no evidence that the required process exists or was ever applied.

Examples of major NCs:

"No documented risk treatment plan per Chapters 6.1.3 and 8.3 of the standard exists. Risks were identified and assessed in the risk register, but there is no formal assignment of treatment measures, responsible persons, and implementation deadlines. Without a risk treatment plan, it cannot be demonstrated that identified risks are systematically treated."

"No management review per Chapter 9.3 has been conducted. The last documented management review dates from March 2024. For the period April 2024 to March 2026, no evidence exists for an evaluation of the ISMS by top management. The required inputs (audit results, risk status, KPIs) were not discussed at management level during the reporting period."

"Access control shows systemic deficiencies: no current access control policy exists (last version from 2022, never formally approved). In none of the ten reviewed cases was there documented approval for access provisioning. Regular access rights reviews are not conducted. Three former employees still had active accounts at the time of the audit."

Assessment Criteria: Making the Decision Objective

The boundary between observation, minor NC, and major NC is not always clear-cut. To make the assessment more consistent and traceable, structured criteria help.

Decision Matrix

Question	Observation	Minor NC	Major NC
Is the standard requirement met?	Yes, but improvement potential	Partially not	No, or only minimally
Does the process exist?	Yes	Yes, but with gaps	No, or only on paper
How many areas are affected?	None directly	One isolated area	Multiple, or one critical area
Is there objective evidence?	Yes, with limitations	Partially	None or insufficient
Is it an isolated case?	Potential pattern	Isolated case or limited	Systemic
Does it endanger ISMS effectiveness?	No	No, local weakness	Yes

The "Accumulation" Rule

An important principle in assessment: multiple minor NCs in the same subject area can be consolidated into a major NC if they indicate a systemic failure.

If you find during access control that the policy is outdated (minor NC), that approvals are missing (minor NC), and that regular reviews are not taking place (minor NC), you don't have a problem with three individual process steps. You have a problem with the entire access control. In this case, it is appropriate to formulate the finding as a major NC, because the sum of individual weaknesses constitutes a systemic problem.

The "Impact" Question

In borderline cases, the following question helps: what would be the consequence if this weakness is not remediated? If the answer is "a single transaction was not correctly documented," lean toward a minor NC. If the answer is "we cannot ensure that our access rights are correct," lean toward a major NC.

The impact does not need to have actually occurred. It is sufficient if the weakness has the potential to substantially impair information security. A missing backup restore test is not a major NC because data was lost, but because you don't know whether your backups work. The risk is the problem, not the damage.

Root Cause Analysis: From Symptom to Cause

The root cause analysis is the step that many organizations skip — yet it determines the success or failure of the corrective action. If you only fix the symptom, you will encounter the same finding at the next audit.

ISO 27001 explicitly requires in Chapter 10.1: in the event of a nonconformity, the organization must determine the cause of the nonconformity to ensure it does not recur. This is not a recommendation — it is a mandatory requirement.

The 5-Why Method

The simplest and most effective technique for root cause analysis is the 5-Why method. You ask "Why?" five times to move from the superficial finding to the underlying cause.

Example:

Finding: For three of ten reviewed access changes, the documented approval is missing.

Why? The changes were carried out directly by the IT team without going through the approval process.

Why? The IT team classified the changes as urgent and skipped the approval step.

Why? There is no defined process for urgent access changes that provides for retroactive approval.

Why? When creating the access control policy, the case of "urgent changes" was not considered.

Why? The policy was created without involving the IT team, which best understands the practical requirements.

Root Cause: The access control policy was created without sufficient involvement of operational stakeholders and does not cover all practically relevant scenarios.

Do you see the difference? The superficial correction would have been: "Instruct the IT team to follow the approval process in the future." That would fix the symptom short-term but not the cause. The root-cause-based correction is: "Revise the access control policy with IT team involvement and define a process for urgent changes with retroactive approval."

Ishikawa Diagram for Complex Cases

For major NCs or findings with multiple possible causes, an Ishikawa diagram (fishbone diagram) can be helpful. It structures the cause analysis along categories:

People: Lack of knowledge, insufficient training, lack of motivation, staff turnover
Method: Missing or insufficient process, unclear responsibilities, missing escalation paths
Material: Missing or outdated tools, insufficient technical equipment
Measurement: Missing KPIs, no monitoring, no feedback loops
Environment: Organizational culture, leadership behavior, resource constraints, time pressure

For most audit findings in an ISMS, the 5-Why method is sufficient. The Ishikawa diagram is more suited for complex, systemic problems where multiple causes interact.

Common Root Causes in ISMS Audits

From the experience of many audits, certain cause patterns crystallize:

Missing process integration: The ISMS process exists but is not integrated into operational workflows. The access control policy sits in the ISMS folder, but the IT service desk does not know it and works according to their own rules.

Resource constraints: The ISO has 20% of their working time for the ISMS but would need 50%. The consequence: only the bare minimum gets done, proactive improvements fall by the wayside.

Knowledge gaps: The responsible persons do not know the standard requirements in detail or do not understand what the internal policy concretely expects of them. A targeted security awareness program helps close these gaps.

Missing tools: Processes are performed manually (Excel spreadsheets, emails), which leads to inconsistencies and forgotten steps. Switching from Excel ISMS to a tool solves many of these problems.

Organizational changes: A personnel change, a restructuring, or a new business application has made existing processes obsolete without the ISMS being updated.

Lack of management support: Senior management formally approved the ISMS but does not actively support it. The article on communicating ISMS to senior management shows how to approach this. Information security has no priority in day-to-day prioritization.

Knowing the root cause fundamentally changes the type of corrective action. If the cause is "missing training," a technical tool won't help. If the cause is "resource constraints," a better policy won't help. The action must match the cause.

Defining and Tracking Corrective Actions

Immediate Action vs. Corrective Action

Chapter 10.1 of the standard distinguishes between two responses to a nonconformity:

Immediate action (Correction): Fixes the immediate problem. The former employee whose account was still active is deactivated immediately. The overdue policy review is conducted. The missing approval is obtained retroactively.

Corrective action: Eliminates the cause so the problem does not recur. The offboarding process is revised so that IT is automatically notified of every departure. The policy review is anchored in the calendar and escalated to the ISO when the deadline approaches.

Both are needed. The immediate action resolves the acute condition; the corrective action prevents recurrence. A common mistake: organizations carry out the immediate action and forget the corrective action. At the next audit, the same finding appears again, and the auditor rightfully asks whether the organization is capable of learning.

Criteria for Good Corrective Actions

An effective corrective action meets five criteria:

Specific: "The access control policy will be supplemented with a chapter on urgent access changes that defines an emergency process with retroactive approval within 48 hours" rather than "Access control will be improved."

Cause-oriented: The action addresses the cause identified in the root cause analysis, not the symptom.

Time-bound: There is a clear deadline for implementation. Without a deadline, there is no urgency, and the action slides down the priority list.

Assigned: There is a named person responsible for implementation. "The IT team" is not a responsible person. "Maria Schneider, IT Manager" is.

Verifiable: It is defined how the effectiveness of the action can be verified. What is the evidence that the action worked?

Action Item Template

For each corrective action, a structured template is recommended:

Field	Content
Action No.	CA-2026-005
Associated Finding	AUD-2026-003 (Minor NC: Missing approvals for access changes)
Root Cause	Access control policy does not cover the case of urgent changes; policy was created without involving the IT team
Immediate Action	Obtain retroactive approval for the three affected access changes (Resp.: K. Weber, Deadline: Mar 20, 2026)
Corrective Action	1. Revise access control policy with IT team involvement, add emergency process with retroactive approval. 2. Train all IT staff on the updated process. 3. Introduce quarterly spot check of 5 access changes.
Responsible	M. Schneider (IT Manager)
Implementation Deadline	Apr 30, 2026
Effectiveness Review	Spot check of 10 access changes in the period May-July 2026. Target: 100% documented approvals.
Review Date	Jul 31, 2026
Status	Open

Prioritizing Actions

Not all actions have the same urgency. A sensible prioritization considers:

Criticality of the finding: Major NCs take priority over minor NCs. If a major NC is open during a certification audit, the certificate will not be issued.

Risk: Actions addressing a high security risk take priority over those primarily closing documentation gaps.

Dependencies: Some actions must be implemented in a specific order. The policy revision must precede the training because the training is based on the updated policy.

Resource availability: Pragmatic reality: if the sole IT administrator is currently managing a critical migration project, the action implementation cannot run in parallel. This is acceptable as long as the prioritization is documented and approved by management.

Typical Timelines

Finding Category	Submit Action Plan	Complete Implementation	Verify Effectiveness
Major NC (certification audit)	2 weeks	90 days	Within 6 months
Major NC (internal audit)	2 weeks	90 days	At next audit or after 6 months
Minor NC	4 weeks	90 days	At next regular audit
Observation	No formal plan needed	Recommendation: before next audit	At next audit

These timelines are not prescribed in the standard but have proven practical. Adapt them to your organization's circumstances, but document the defined timelines in the audit program.

Effectiveness Review: The Often-Forgotten Step

The effectiveness review is the step that distinguishes a corrective action from a mere work assignment. ISO 27001 explicitly requires in Chapter 10.1 that the organization evaluates the effectiveness of every corrective action taken. Without an effectiveness review, the action is not complete, regardless of whether it was implemented.

What Effectiveness Means

Effectiveness does not mean merely that the action was implemented. It means that the cause has been eliminated and the nonconformity does not recur. The difference is fundamental:

Implemented: The access control policy was revised and IT staff were trained. The action is technically complete.
Effective: In a spot check of ten access changes after the training, documented approval is present in all cases. The cause of the original finding has actually been eliminated.

Methods of Effectiveness Review

Spot check: The most common method. You check a defined number of cases after the action implementation and determine whether the problem is resolved. For access changes, you check ten changes and see whether all are approved.

Data analysis: If you have KPIs that measure the affected area, you can compare the data before and after the action. The patch rate was 80% before the action, 97% after introducing automated patch management. Effective.

Interview: You ask the affected persons whether the new process works and whether they have difficulties with implementation. This method alone is not sufficient as effectiveness evidence but complements objective data with a qualitative perspective.

Observation: You observe the process in action. For physical security (e.g., access control), you go on-site and check whether the action works as planned.

Follow-up audit: For major NCs, a formal follow-up audit is recommended. This is a focused mini-audit that exclusively reviews the affected finding and the associated corrective action. It follows the same methodology as the original audit (interviews, document review, sampling) but is significantly smaller in scope.

Documenting the Effectiveness Review

For each effectiveness review, document:

Date of the review
Reviewer (does not need to be the original auditor, but someone independent)
Review method (spot check, data analysis, interview, observation)
Result (effective / partially effective / not effective)
Objective evidence (What was checked? What was found?)
Assessment and next steps

If the action is assessed as not effective, the cycle starts over: new root cause analysis (why did the action not work?), new corrective action, new effectiveness review.

Follow-Up Audit: When and How

A follow-up audit is a focused audit that specifically checks whether the corrective actions for open nonconformities have been effectively implemented. It is not a full audit but a targeted verification.

When a Follow-Up Audit Is Appropriate

Always for major NCs: A major NC endangers the effectiveness of the ISMS. You do not want to wait until the next regular audit to check whether the problem is solved.
For recurring minor NCs: If the same minor NC appears for the second or third time, it indicates that previous corrective actions were not effective. A follow-up audit specifically checks whether the new approach works better.
Before the certification audit: If the internal audit produced findings and the certification audit is in a few months, a follow-up audit gives you confidence that the findings are closed.

Follow-Up Audit Process

The process is significantly more compact than a regular audit:

Preparation (1-2 hours): Re-read the original finding, the root cause analysis, and the defined corrective action. Set review criteria for effectiveness.
Execution (2-4 hours): Conversation with the action owner, inspection of the implemented action, spot check for effectiveness.
Assessment and documentation (1-2 hours): Document the result, assess the finding as closed or still open.

The entire follow-up audit for a single finding typically takes half a working day. For multiple related findings, it can be a full day.

Follow-Up Audit Results

The follow-up audit has three possible outcomes:

Finding closed: The corrective action was implemented and is effective. The cause is eliminated; the problem no longer occurs. The finding is marked as closed in the audit tracker.

Finding still open, progress visible: The action was partially implemented or is still in implementation. The deadline is extended, and another follow-up audit is scheduled.

Finding still open, no progress: The action was not implemented or is evidently not effective. This situation requires escalation to management. If despite defined actions and deadlines no progress is visible, the problem may lie not at the operational but at the leadership level.

Managing the Entire Cycle

Audit findings, root cause analyses, corrective actions, effectiveness reviews, and follow-up audits together form a closed feedback loop. This loop is the heart of continuous improvement per ISO 27001.

Putting It All Together: The Lifecycle of a Finding

Phase	Activity	Responsible	Timeframe
1. Finding	Document and categorize the audit finding	Auditor	During the audit
2. Communication	Create audit report and distribute to affected parties	Auditor / ISO	1-2 weeks after audit
3. Root Cause	Conduct root cause analysis	Affected unit	2-4 weeks after report
4. Action Plan	Define immediate and corrective actions	Affected unit	Together with root cause
5. Approval	Approve action plan through ISO / management	ISO / Management	1 week after submission
6. Implementation	Implement actions	Responsible per plan	Per deadline (typical 30-90 days)
7. Effectiveness Review	Check whether the action works	Auditor / ISO	3-6 months after implementation
8. Closure	Mark finding as closed or start new cycle	ISO	After positive effectiveness review
9. Reporting	Feed overall status into management review	ISO	At the next management review

Tracking in Practice

In practice, the action cycle rarely fails due to lack of knowledge, but due to lack of tracking. Actions get lost, deadlines pass, effectiveness reviews are forgotten. A reliable tracking system is therefore indispensable.

The requirements for such a system are manageable:

Central capture of all findings and actions
Status tracking with traffic-light logic (open, in progress, overdue, closed)
Deadline monitoring with automatic reminders
Linking findings, root causes, actions, and effectiveness reviews
Reports for the management review (count by category, trend, open actions)

Whether you solve this with an Excel spreadsheet, project management software, or a specialized ISMS tool like ISMS Lite depends on your organization's size and the number of findings. ISMS Lite costs 500 Euro pro Jahr and covers action tracking, deadline monitoring, and audit documentation without seat licenses. For a company with fewer than 100 employees and ten to twenty findings per year, a well-maintained spreadsheet can suffice. Beyond that, a dedicated tool pays off, one that automates reminders and delivers reports at the push of a button.