Network Audit Findings Report

Findings{{ resultsReady ? computation.values.total_findings : '—' }} Priority{{ resultsReady ? computation.values.priority_findings : '—' }} Overdue{{ resultsReady ? computation.values.overdue_findings : '—' }}

Findings CSV:

The source stays in your browser. CSV or TXT files are limited to 2 MB.

Audit name:

This label identifies the exported report.

Audit date:

Due dates before this day are overdue.

Auditor or team:

Use a team name when several reviewers contributed.

Escalation threshold:

The register and chart still include every severity.

Due-soon window:

Choose 1 to 120 calendar days.

days

Scope note:

The neutral default is blank; it appears only in the audit brief.

{{ computation.values.report_text }}

The chart renderer is unavailable. The same rows remain available in the finding register.

ID	Priority	Severity	Area	Asset	Finding	Owner	Status	Due	Evidence	Next action	Score	Copy
{{ row.id }}	{{ row.priority }}	{{ row.severity }}	{{ row.area }}	{{ row.asset }}	{{ row.finding }}	{{ row.owner }}	{{ row.status }}	{{ row.due \|\| '—' }}	{{ row.evidence }}	{{ row.next_action }}	{{ row.score }}

A network audit ends with decisions, not observations. Firewall rules, route behavior, wireless policy, segmentation, device hardening, and operational controls may all produce findings, but each finding still needs enough context to become safe, assignable remediation work.

The strongest finding records connect five things: the affected asset, the technical condition, supporting evidence, an accountable owner, and a way to confirm the fix. Severity helps set an initial review order. It does not replace judgment about exposure, business importance, exploitability, compensating controls, maintenance risk, or the consequences of a failed change.

Essential parts of a useful network audit finding
Finding part	Question it should answer	Weak record example
Scope and evidence	Where was the condition observed, and what proves it?	“Firewall issue” with no rule, interface, or test result.
Severity	How urgently should the technical risk be reviewed?	A label copied from a scanner without validation.
Owner and due date	Who can act, and when should the action be checked?	An urgent item assigned to “TBD” with no date.
Remediation and closure proof	What should change, and what retest will show that it worked?	“Fix configuration” without a safe change or validation step.

Dates need a consistent review boundary. A target date that has passed is different from one approaching soon, and both are different from a row with no usable date. Closed and accepted findings also need separate treatment from active work. Acceptance records a risk decision; it does not prove that the condition disappeared.

Common reporting failures are easy to miss when the spreadsheet looks complete. Rows can contain severe labels but no evidence, active work can lack an owner, and a long list can bury the few items that need escalation today. A remediation register should reveal those gaps without pretending that an automatically assigned score is a formal risk assessment.

Before any network change, confirm the finding against current device state, the approved scope, the maintenance window, and the rollback plan. Audit triage can focus attention; authorized engineers still decide whether and how a production change should proceed.

How to Use This Tool:

Start with one CSV row per finding, then choose the date and severity boundary that should govern this review.

Paste Findings CSV or browse for a CSV or TXT file. A header row is recommended; include severity, area, asset, finding, owner, status, due date, evidence, and remediation where available.
Enter the Audit name, Audit date, and Auditor or team. The audit date is the boundary used to classify overdue and due-soon work.
Choose the Escalation threshold and a Due-soon window from 1 to 120 days. The threshold changes the active escalation count, not which severities remain in the register.
Review the summary before using the report. Correct unusable rows, confirm unassigned owners and missing evidence, then compare the generated priority order with the underlying technical risk.

Interpreting Results:

The escalation count includes only active findings whose normalized severity is at or above the selected threshold. Closed and Accepted rows remain visible but do not trigger that count.

Priority is a local triage score that combines severity with active status, deadline pressure, ownership, evidence, and remediation gaps.
Overdue means the due date is earlier than the audit date. A date on the audit day is due soon, not overdue.
Evidence gaps count rows missing evidence, remediation detail, or both. One row still contributes only one gap count.
Verify the highest-ranked rows against the source devices, tickets, and approved risk process before escalating or changing a network.

Technical Details:

Each usable row is normalized before ranking. Recognized severity aliases map to Critical, High, Medium, or Low; an unrecognized value becomes Info. Status text containing closed, resolved, remediated, done, or complete becomes Closed, while acceptance or waiver wording becomes Accepted. Other recognized active states become In progress or Blocked, and unmatched status text becomes Open.

Formula Core:

The finding score is a transparent prioritization heuristic. It is capped at 130 and is not a probability, loss estimate, or standards-based risk rating.

S = \min (130, B_{severity} + A_{active} + D_{due} + O_{owner} + E_{evidence} + R_{remediation})

Network audit finding score terms
Term	Points	Condition
Severity base	100 / 75 / 45 / 20 / 5	Critical / High / Medium / Low / Info
Active	+10	Status is neither Closed nor Accepted
Due state	+18 or +8	Overdue, otherwise due within the selected window including its final day
Owner gap	+8	No owner was supplied
Evidence gap	+4	No evidence was supplied
Remediation gap	+4	No remediation was supplied

Rule Core:

Score bands assign queue labels after the additions are complete. Findings are sorted by descending score, with original row order breaking a tie.

Priority score boundaries
Priority	Score rule
P0	S ≥ 110
P1	85 ≤ S < 110
P2	60 ≤ S < 85
P3	35 ≤ S < 60
P4	S < 35

A valid due date is compared as a calendar day. A negative day difference is Overdue; a difference from 0 through the chosen due-soon window is Due soon; a later date is Scheduled. Missing or invalid date text becomes No due date and adds no deadline points.

Escalation uses severity rank rather than the score. Critical-only requires Critical. High or Critical accepts either of those severities. Medium or higher also accepts Medium. This keeps an evidence gap or missed date from silently changing the stated severity gate.

Limitations and Privacy Notes:

The ranking model cannot determine exploitability, exposure, business impact, compensating controls, or whether evidence is true. Treat it as a queue aid, then apply the organization’s approved risk and change processes.

CSV parsing supports quoted commas, but malformed quoting or unusual column layouts can still produce misleading fields.
Severity aliases and status keywords are normalized mechanically; review unexpected source vocabulary.
Finding text and local files are processed in the browser. Avoid placing credentials, private keys, or paging secrets in the report.

Worked Examples:

Active high finding due today

An active High finding starts at 75 points, gains 10 for active status and 8 because a due date on the audit day is within the due-soon window. Its score is 93, so it enters P1. With a High-or-Critical gate, it also contributes to the escalation count.

Accepted critical finding

A Critical row begins at 100 points but receives no active-status or deadline points when its status is Accepted. It remains prominent in the register, yet it is excluded from the active queue and escalation count. The acceptance evidence still needs independent review.

References:

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, National Institute of Standards and Technology, September 2008.
NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments, National Institute of Standards and Technology, September 2012.
How to audit Docker iptables rules, Simplified Guide.