From network observations to reviewable evidence
Episode 05 — Evidence and review

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

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

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

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

[00:00:42.661] Write the proposed claim in plain language before choosing a screenshot. Ask what evidence would support that particular claim.

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

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

[00:01:12.813] List exclusions explicitly, including other lines, unobserved networks and services outside the exercise. Name the owner who agreed this scope.

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

[00:01:33.830] Create a stable evidence identifier and a short description. Link the record to its source file, collection point and responsible custodian.

[00:01:44.085] Store the evidence in an approved location with suitable permissions. Use references that an authorised reviewer can actually follow.

[00:01:53.184] Avoid relying on a filename such as final screenshot. A clear identifier and register entry make later questions much easier to resolve.

[00:02:04.534] Record when the traffic was observed, including the time zone and any known clock limitations. Keep the original observation window visible.

[00:02:14.371] Also record when the file was imported, processed and reviewed. These dates answer different questions and should remain distinct.

[00:02:23.334] A capture imported this morning may describe last week’s activity. A newly generated report does not make the underlying observation current.

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

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

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

[00:03:07.879] Observed means the source directly supports the statement. For example, a capture contains communication between two addresses during the stated window.

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

[00:03:28.321] Owner reviewed means a named person confirmed a particular statement using appropriate knowledge or supporting records. State exactly what they confirmed.

[00:03:40.334] Our fictional record describes an operator panel communicating with a controller on packaging line A during a one-hour observation window.

[00:03:50.578] Link the statement to the relevant capture and event references. Record the observed addresses and protocol detail that supports it.

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

[00:04:13.380] Ask the controls engineer and process owner what the observed communication supports. Compare it with drawings, configuration records and the approved operating arrangement.

[00:04:25.010] Record who reviewed the explanation, when they did so and which supporting records they used. Keep evidence custody separate from approval responsibility.

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

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

[00:04:58.753] Check capture loss, collection interruptions and processing failures where that information is available. Keep unknown health information visible.

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

[00:05:20.757] Not observed means the source did not show it within the stated coverage. It does not automatically mean absent, offline or prohibited.

[00:05:30.218] Not yet verified means a question still needs evidence or review. A confirmed issue needs supporting facts and a clear description of its consequence.

[00:05:40.505] Keep these categories distinct in the register. Give each unresolved gap a named owner, next action and target review date.

[00:05:50.753] A useful register brings together the claim, scope, source reference, observation dates, processing details, owner and review status.

[00:06:00.410] Add the conclusion’s limits and any open action. Include a link to the underlying material rather than pasting an unsupported summary.

[00:06:09.877] Keep entries short enough to review. An evidence index can point to detailed technical records without putting every packet into the management summary.

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

[00:06:31.587] Reference the inventory and coverage note. State that other lines or unobserved operating conditions remain outside that evidence.

[00:06:41.055] If the questionnaire requires a yes or no, follow its instructions and agree the response with the authorised business owner. Add the necessary qualification.

[00:06:52.621] Record the exact customer question or framework reference, then explain why each evidence item is relevant to it.

[00:07:00.962] 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.

[00:07:11.525] Keep a separate column for evidence still required, such as policies, access reviews, recovery tests or incident-handling records.

[00:07:22.147] IEC 62443-3-2 starts with the system under consideration, an initial cybersecurity risk assessment, and partitioning into zones and conduits.

[00:07:33.971] 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.

[00:07:45.885] 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.

[00:07:58.631] Develop credible threat scenarios using the system context, relevant vulnerabilities and potential operational consequences. Involve operations, controls and safety specialists where appropriate.

[00:08:12.431] 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.

[00:08:25.611] 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.

[00:08:38.523] Evaluate existing countermeasures and any additional measures needed. Reassess the risk and retain the rationale, supporting evidence and remaining uncertainties.

[00:08:49.533] 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.

[00:09:02.720] 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.

[00:09:16.452] For NIS2 preparation, first confirm whether and how the organisation is in scope under the relevant national implementation and sector arrangements.

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

[00:09:37.256] 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.

[00:09:49.724] For an NCSC Cyber Assessment Framework review, agree the relevant version, assessment scope and any applicable sector profile with the reviewing organisation.

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

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

[00:10:23.930] Where a question concerns effectiveness, add suitable validation or test records alongside the observation. Keep the test scope, expected result and actual outcome.

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

[00:10:46.446] Record the resulting actions and any later recheck. A screenshot showing that a feature exists is different from evidence that the process worked.

[00:10:57.840] Before sending an evidence pack, agree its audience, purpose and approved contents. Captures, diagrams and reports can reveal sensitive operational information.

[00:11:09.217] Use a reviewed redacted copy where appropriate. Preserve the controlled original and record the redaction so the reader understands any relevant omissions.

[00:11:19.433] Check links, file versions and access permissions. Have the authorised owner approve the release and keep the issued version with its date.

[00:11:29.732] Set review triggers for equipment changes, supplier access, network changes and new findings. Agree a review interval that fits the purpose of the evidence.

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

[00:11:49.609] When closing an action, record what changed, who checked it and the supporting evidence. An action marked complete needs a reviewable reason.

[00:12:00.579] Start with one question and one production function. Give each observation a source reference, clear dates and the limits of its coverage.

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

[00:12:19.732] That gives customers and assessors a clearer basis for review, while keeping your conclusions within the evidence available. Thank you.


[00:12:30.000] End card: Thank you.
