Verification and validation policy and test procedure

Verification and validation policy and test procedure

VE-01 — Verification and validation policy

[Organisation] plans and performs verification to establish whether specified requirements have been fulfilled, and validation to establish whether the system satisfies stakeholder needs in its intended use. The verification lead maintains the plan, coverage and results. The system owner arranges stakeholder participation and acceptance decisions. The scope of a conclusion is limited to the evidence actually obtained.

Testing is one evidence method alongside examination, analysis and demonstration. Methods are selected according to the property, risk and practical conditions. Test effort covers security and privacy requirements, integration, error handling, recovery and operational behaviour as applicable. The plan identifies any requirement for assessor independence and records where the same person develops and evaluates the work.

VE-02 — Plan scope and criteria

The lead identifies the requirements baseline, system configuration, interfaces and operating conditions to be assessed. Each planned check identifies its objective, method, inputs, expected result, responsible person and evidence. Acceptance thresholds are agreed before results are evaluated. Coverage identifies the requirements or scenarios assessed and the portions outside scope.

The plan includes component, integration and system-level checks where needed to establish the required properties. It addresses regression after change, unsuccessful operations, boundary values, unauthorised actions, concurrent activity and restoration. Performance and resource behaviour are assessed against agreed limits where they affect essential service. Supplier and inherited evidence is evaluated for applicability before it is credited.

VE-03 — Security assessment activities

The lead selects source analysis, dependency analysis, dynamic testing, configuration review, penetration testing or other methods appropriate to the system. Selection records which classes of weakness or requirements each method can address. Tool configuration, rule sets, exclusions and limitations are retained where they materially affect interpretation. A clean tool report is not represented as proof that all security requirements are satisfied.

Security testing that can affect a live service or another party uses an agreed scope and authority. The test arrangement identifies targets, permitted methods, timing, information handling, contacts and conditions for pausing or ending activity. Findings describe the observed behaviour and evidence. Speculative concerns and confirmed exploitable conditions are distinguished, with follow-up work where confirmation is required.

VE-04 — Environment and test information

The test environment is identified by version and configuration. The record states material differences from the intended operating environment, including identity, network, data volume, supplier services and monitoring. Simulations or substitutes identify the assumptions they introduce. The lead records whether those differences limit the conclusion or require further validation.

Test information is selected under the data and privacy policies. Access and retention arrangements protect sensitive inputs, outputs and diagnostic records. Expected outputs are established from the requirement or another justified source. The team preserves failing inputs and relevant state sufficiently to investigate a result, while limiting unnecessary retention of personal information or secrets.

VE-05 — Execute and record

The performer confirms the test objective, authorised scope and target configuration before execution. The result record identifies the method or command, inputs, start and completion time, actual outcome and evidence location. Deviations from the plan are recorded with their reason and effect. Interrupted or incomplete checks are identified as such, rather than reported as successful.

Results remain connected to the source, build and deployment configuration examined. Evidence is retained in a form that permits review of the relevant claim. Screenshots can support a visible outcome but may not establish underlying permissions or configuration. Logs can establish recorded events but require context about their source, completeness and integrity.

VE-06 — Findings, correction and retest

The lead records deviations from expected results as findings with affected requirements, consequence, evidence and owner. Security findings enter the vulnerability process where appropriate. The responsible owner investigates, proposes correction or a risk decision, and records the disposition. A rejected finding includes the evidence and rationale supporting rejection.

After correction, the performer repeats the relevant check on the changed configuration and assesses regression implications. Closure identifies the retest evidence and reviewer. A change that removes the failing test without resolving its underlying requirement is recorded as a requirements or scope decision, not a successful correction. Findings accepted for release remain visible in the release and risk records.

VE-07 — Validation and assessment report

Validation uses the intended tasks, users and operating conditions to the extent established in the plan. The participants assess whether the system enables the required outcome, including its behaviour under relevant failures and limitations. Feedback that exposes a mismatch between a written requirement and a stakeholder need is returned to the requirements owner.

The report states the configuration, period, scope, methods, coverage, results, open findings and limitations. It identifies unperformed work and the confidence supported by the available evidence. The decision authority receives the report with outstanding risks and corrective actions. The report does not silently convert a release decision into a claim that every test or requirement passed.