From network observations to reviewable evidence

From network observations to reviewable evidence

Welcome back. I am Sam Armstrong. This episode turns network observations into evidence that another person can understand and review.

We will follow an illustrative packaging-line observation through a small evidence register and into a customer questionnaire response.

We will also connect evidence to IEC 62443-3-2 risk assessment, and preparation for relevant NIS2 or NCSC Cyber Assessment Framework reviews.

Define the claim you need to support.

Start with the actual question. A customer may ask about asset management, monitoring coverage, supplier access or the review of security events.

Write the proposed claim in plain language before choosing a screenshot. Ask what evidence would support that particular claim.

A network map might help explain observed relationships. It does not by itself demonstrate the whole organisation’s asset-management process.

Say which function and systems are covered.

For our example, the review covers packaging line A at one site. Identify its operational function, supporting assets and relevant shared services.

List exclusions explicitly, including other lines, unobserved networks and services outside the exercise. Name the owner who agreed this scope.

Keep this boundary with every evidence summary. A reader should not have to guess whether one capture represents one line or the entire factory.

Give each item a stable reference.

Create a stable evidence identifier and a short description. Link the record to its source file, collection point and responsible custodian.

Store the evidence in an approved location with suitable permissions. Use references that an authorised reviewer can actually follow.

Avoid relying on a filename such as final screenshot. A clear identifier and register entry make later questions much easier to resolve.

Separate observation from processing and review.

Record when the traffic was observed, including the time zone and any known clock limitations. Keep the original observation window visible.

Also record when the file was imported, processed and reviewed. These dates answer different questions and should remain distinct.

A capture imported this morning may describe last week’s activity. A newly generated report does not make the underlying observation current.

Keep the source and how it was handled.

Keep the original evidence or an approved preserved source copy according to your handling procedure. Record its origin and any relevant collection notes.

A recorded cryptographic hash helps compare file bytes later. Also record the tool version, processing settings and transformations applied to working copies.

A matching hash does not establish that the source was complete or accurate. It supports integrity checks alongside the handling record and other context.

Use three clear evidence labels.

Observed means the source directly supports the statement. For example, a capture contains communication between two addresses during the stated window.

Inferred means an interpretation, such as a likely device role. Record the reasoning and uncertainty rather than silently promoting it to fact.

Owner reviewed means a named person confirmed a particular statement using appropriate knowledge or supporting records. State exactly what they confirmed.

Keep the observation narrow and traceable.

Our fictional record describes an operator panel communicating with a controller on packaging line A during a one-hour observation window.

Link the statement to the relevant capture and event references. Record the observed addresses and protocol detail that supports it.

This establishes an observed relationship in that window. It does not establish continuous availability, authorised access, a correct configuration or a successful control test.

Have the right owner review the meaning.

Ask the controls engineer and process owner what the observed communication supports. Compare it with drawings, configuration records and the approved operating arrangement.

Record who reviewed the explanation, when they did so and which supporting records they used. Keep evidence custody separate from approval responsibility.

If a question remains unresolved, assign an action owner and review date. Reviewing a finding does not automatically mean accepting the associated risk.

Explain what the collection could see.

Describe the collection point, included networks and traffic directions. Record which operating conditions were represented, such as normal running or a planned changeover.

Check capture loss, collection interruptions and processing failures where that information is available. Keep unknown health information visible.

Explain whether maintenance, startup or supplier access was outside the observation window. A short capture cannot establish that those activities never occur.

Separate missing evidence from a failed control.

Not observed means the source did not show it within the stated coverage. It does not automatically mean absent, offline or prohibited.

Not yet verified means a question still needs evidence or review. A confirmed issue needs supporting facts and a clear description of its consequence.

Keep these categories distinct in the register. Give each unresolved gap a named owner, next action and target review date.

Make each record reviewable on its own.

A useful register brings together the claim, scope, source reference, observation dates, processing details, owner and review status.

Add the conclusion’s limits and any open action. Include a link to the underlying material rather than pasting an unsupported summary.

Keep entries short enough to review. An evidence index can point to detailed technical records without putting every packet into the management summary.

Use a bounded, evidence-linked response.

For an asset-visibility question, say that packaging line A has an observation-based inventory for the stated window, with an owner review recorded.

Reference the inventory and coverage note. State that other lines or unobserved operating conditions remain outside that evidence.

If the questionnaire requires a yes or no, follow its instructions and agree the response with the authorised business owner. Add the necessary qualification.

Map the relevance without overstating it.

Record the exact customer question or framework reference, then explain why each evidence item is relevant to it.

One item may support several questions, but the connection should be explained for each. An inventory and a monitoring record support different parts of a review.

Keep a separate column for evidence still required, such as policies, access reviews, recovery tests or incident-handling records.

Connect the evidence to the risk assessment.

IEC 62443-3-2 starts with the system under consideration, an initial cybersecurity risk assessment, and partitioning into zones and conduits.

Compare the initial risk with the organisation’s tolerable risk to determine the need for detailed assessment. Link relevant observations to the scoped assets, zones and conduits.

Keep the assessment method, risk criteria and architecture references with the evidence. Use the applicable standard and the asset owner’s approved process for the assessment.

Use plant knowledge to evaluate scenarios.

Develop credible threat scenarios using the system context, relevant vulnerabilities and potential operational consequences. Involve operations, controls and safety specialists where appropriate.

For each scenario, assess consequences and unmitigated likelihood using the approved criteria. Packet counts and vulnerability severity scores do not determine operational risk on their own.

Document unmitigated risk and target security levels. A four-by-four risk matrix may be a locally approved method; the standard does not mandate that exact matrix.

Keep the treatment and approval trail.

Evaluate existing countermeasures and any additional measures needed. Reassess the risk and retain the rationale, supporting evidence and remaining uncertainties.

Document the security requirements, assumptions and constraints, with treatment owners and validation actions. Proposed measures need their implementation and effectiveness checked before being credited as effective.

Compare residual risk with the tolerable criteria and retain the asset owner’s approval. Escalate unresolved risk through the agreed process; a network report alone cannot close it.

Confirm the applicable requirements first.

For NIS2 preparation, first confirm whether and how the organisation is in scope under the relevant national implementation and sector arrangements.

Network observations can contribute to technical evidence. They do not cover the full governance, organisational and risk-management picture needed for a review.

Do not infer compliance from a report or mapping. Have the responsible legal, compliance and security owners agree the applicable requirements and the evidence needed.

Use the agreed CAF version and profile.

For an NCSC Cyber Assessment Framework review, agree the relevant version, assessment scope and any applicable sector profile with the reviewing organisation.

Use evidence to explain how the relevant outcomes are met in practice. The indicators inform the review; assessment still needs expertise and context.

A network observation may support a monitoring discussion. It cannot on its own establish the effectiveness of all monitoring, response or governance arrangements.

Show the review and the resulting action.

Where a question concerns effectiveness, add suitable validation or test records alongside the observation. Keep the test scope, expected result and actual outcome.

For example, an approved exercise might check whether a relevant alert was generated, reviewed by the responsible person and handled through the agreed process.

Record the resulting actions and any later recheck. A screenshot showing that a feature exists is different from evidence that the process worked.

Protect the detail behind the summary.

Before sending an evidence pack, agree its audience, purpose and approved contents. Captures, diagrams and reports can reveal sensitive operational information.

Use a reviewed redacted copy where appropriate. Preserve the controlled original and record the redaction so the reader understands any relevant omissions.

Check links, file versions and access permissions. Have the authorised owner approve the release and keep the issued version with its date.

Review changes and close the loop.

Set review triggers for equipment changes, supplier access, network changes and new findings. Agree a review interval that fits the purpose of the evidence.

Retain version history and show when an item is superseded. Do not overwrite the meaning of an old observation with a new import date.

When closing an action, record what changed, who checked it and the supporting evidence. An action marked complete needs a reviewable reason.

A clear claim. A source. An owner. A visible gap.

Start with one question and one production function. Give each observation a source reference, clear dates and the limits of its coverage.

Add the owner’s review, link the evidence to the relevant request or risk assessment, and keep unresolved gaps visible with named next actions.

That gives customers and assessors a clearer basis for review, while keeping your conclusions within the evidence available. Thank you.