LinkedIn Facebook X (Twitter) WhatsApp Telegram Reddit WeChat Copy Link
💡 Insight Article 7 IACS UR E27 Marine Equipment Suppliers

How Can a Statement That a Function Exists Be Converted into Verifiable Evidence?

Article 7 of a 12-Part Series on UR E27 Strategies for Marine Equipment Suppliers

※ The product examples, document numbers, and identifiers described in this article are illustrative examples created to explain how a verifiable UR E27 Evidence Package can be structured.

Blue Horizonist
Blue Horizonist (Lew)
Maritime & Cyber Security Consultant · ISP Consultant

The previous article explained that the object of approval or conformity verification is not simply a product name, but a specific product Baseline combining Hardware, Software, Firmware, Interfaces, security settings, and conditions of application. Once the product Baseline has been established, the next step is to organize the Evidence so that the classification society and shipyard can verify how the product addresses the UR E27 requirements.

At this stage, equipment manufacturers often make the following statement.

"This function has already been implemented in the product."

In conformity verification, however, merely claiming that a function exists is not enough. The manufacturer should be able to answer the following questions.



  • In which product Baseline is it implemented?
  • Which requirement is the function intended to address?
  • What specific control has been implemented in the product to address the requirement?
  • Under which settings and conditions does the function operate?
  • Where can it be verified in the design documents and manuals?
  • What test results demonstrate that it actually operates as intended?
  • Which parts depend on security controls outside the product?
  • Can the existing Evidence still be used if the product or its settings change?

An Evidence Package is therefore not merely a collection of related documents submitted in large quantities. It is a structured body of substantiating material that links the applicable requirements, product design, settings, test results, and operating conditions so that the reviewer can trace the basis for the conformity decision.

This article examines how to link the Product Description, Hardware/Software Inventory, Network Diagram, Interface List, Hardening Guide, management procedures, and test results to the Requirement–Design–Evidence Matrix, and how to build a verifiable Evidence Package without unnecessarily increasing the volume of documentation.

※ In this article, Evidence is used as an inclusive term covering design documents, configuration information, setting records, procedures, test procedures, test results, and approval records that explain or demonstrate product conformity. The names and scope of the actual submission documents may vary according to the applicable classification society's Rules and Guidance and the project-specific submission requirements.

1The Purpose of Evidence Is to Enable a Decision, Not Merely to Provide an Explanation

Good Evidence is different from material that simply describes a product in detail. Product literature is intended to communicate features and benefits, whereas conformity Evidence should enable the reviewer to determine the following.

  • Does the requirement apply to the product?
  • What control has been implemented in the product to address the requirement?
  • Is the control implemented through product functionality, product Configuration, the manufacturer's internal procedures, or the vessel-wide security architecture?
  • Does the design description match the actual product Configuration?
  • Has operation of the control been confirmed through testing?
  • Are unmet elements and external dependencies clearly managed?

For example, even if the Product Description states that "the product provides user authentication," the reviewer will have difficulty determining conformity without the following information.

  • Access paths to which authentication applies
  • User types and roles
  • Functions permitted for each role
  • Method for handling Default accounts
  • Password configuration criteria
  • Restrictions applied after failed login attempts
  • Responsibility for creating, modifying, and deleting accounts
  • Related setting screens or Configuration
  • Test procedures and test results

The quality of Evidence is determined not by the number of pages, but by whether the reviewer can confirm how the requirement has been addressed and verified without having to make additional assumptions.

2Claims, Design, Configuration, and Test Results Should Be Distinguished

The first step in organizing Evidence is to distinguish among the following four elements.

Category What It Confirms Example
Conformity Claim The requirements and scope that the manufacturer considers satisfied "Administrator functions are restricted to authorized accounts."
Design Evidence How the control is implemented through the product structure and functions User role structure, authentication flow, and privilege Matrix
Configuration Evidence Which settings are applied to the delivered Configuration Default-account change record, Password Policy, and active-account list
Test Evidence Whether the designed control actually operates Test result showing that an ordinary user is denied access to the administrator menu

None of these four elements is normally sufficient on its own. A design document does not show whether the setting was applied to the delivered product, while a Screenshot alone does not explain which requirement was tested or why. Even if a test passed, the applicability of its result must be reassessed if the tested Version differs from the delivered Version.

For example, demonstrating the conformity claim that "USB use is restricted" requires at least the following links.

  • Design Evidence: Permitted purposes, users, and approval process for USB use
  • Configuration Evidence: USB storage blocking or allowlist settings
  • Test Evidence: Results showing that ordinary USB devices are blocked and only approved devices are permitted
  • Procedure Evidence: Inspection and usage-record procedures for USB devices used during maintenance

In this way, multiple types of Evidence should complement one another in demonstrating a single requirement.

3The Requirement–Design–Evidence Matrix Is the Center of Traceability, Not Merely a Document List

The Requirement–Design–Evidence Matrix is not a table that simply lists related document names for each requirement. It is a management tool that connects applicability, implementation method, responsible party, verification method, and result in one traceable flow.

In practice, it may include the following fields.

Field Information to Be Recorded
Requirement ID Identifier of the applicable Rule or requirement
Requirement Summary Core intent of the requirement
Applicability Applicable, partially applicable, not applicable, or subject to separate agreement
Applicability Basis Basis for the applicability decision
Control Allocation Product functionality, product Configuration, manufacturer's internal procedures, or vessel-wide security architecture
Design Implementation Specific control implemented in the product
Design Evidence Related design document and Section
Configuration Evidence Setting value, Configuration Record, or Checklist
Verification Method Review, analysis, test, or witnessed test
Test Reference Test Procedure and Test Case ID
Result Reference Test result, Log, Screenshot, or Record
Responsible Party Equipment manufacturer, shipyard, System Integrator, owner, or other party
Dependency Dependency on an external system or operating condition
Status Satisfied, partially satisfied, not satisfied, under discussion, or not applicable
Remark Limitations, compensating controls, and follow-up actions

If the Matrix contains only document names, the reviewer must search through dozens of pages to find the relevant information. Whenever possible, the document number, Revision, Section, Figure, Table, and Test Case ID should therefore be specified.

For example, instead of writing "Account management requirement—refer to User Manual," the reference can be made more specific as follows.

  • Design Evidence: SEC-DD-001 Rev.2, Section 4.3, User Role and Authentication
  • Configuration Evidence: SCG-001 Rev.1, Section 3.2, Account Configuration
  • Verification Method: Functional Test
  • Test Reference: STP-001, TC-AC-01~05
  • Result Reference: STR-001, Appendix B, Screenshots AC-01~05

With this level of traceability, the reviewer can move directly from the requirement to the relevant design and test results.

4One Item of Evidence May Support Multiple Requirements, but Each Link Must Be Explained Separately

There is no need to create a separate description document for every requirement merely to avoid omissions. A single Network Diagram, User and Privilege Matrix, or Software Update procedure may support several requirements.

Even when the same document is referenced, however, the basis for linking it to each requirement must be specific. For example, a Network Diagram may support several different assessments.

  • Identification of the product's external Interfaces
  • Confirmation of Network boundaries
  • Confirmation of remote access paths
  • Confirmation of communication paths to upper-level systems
  • Confirmation of Security Log transmission paths
  • Confirmation of Backup storage locations
  • Confirmation of the responsibility boundary with the vessel-wide security architecture

It is not sufficient to state "refer to the Network Diagram" for every requirement. For a remote access requirement, the remote access path and control points should be identified. For a Log requirement, the Log Source and receiving system should be indicated. For a Network segregation requirement, the connections between Zones and the applicable boundary controls should be identified.

Reusing a document is not the same as referring to it ambiguously. The number of documents may be reduced, but the substantiation for each requirement should not be omitted.

5An Evidence Package Can Be Organized Efficiently in Three Layers

An Evidence Package may be organized into the following three layers to support efficient review.

① Decision and Traceability Layer

This layer enables the reviewer to understand the scope of application and the overall conformity status.

  • Submission document list
  • Product Baseline identification information
  • Approval or verification Scope
  • Requirement–Design–Evidence Matrix
  • List of unmet requirements and compensating controls
  • Project-specific Deviation list
  • External dependencies and responsibility allocation table

② Design and Management Layer

This layer explains how the requirements have been implemented in the product and how that state is maintained.

  • Product Description
  • Hardware/Software Inventory
  • Network Diagram
  • Interface List
  • Port, Protocol and Service List
  • User and Privilege Matrix
  • Security Event List
  • Hardening Guide
  • Backup and Restore Procedure
  • Software Update Procedure
  • Vulnerability Management Procedure
  • Remote Access Procedure
  • Configuration and change management records

③ Verification and Results Layer

This layer demonstrates that the design and settings have actually been implemented and operate as intended.

  • Test Plan
  • Test Procedure
  • Test Configuration
  • Test Record
  • Screenshot
  • Log
  • Configuration Export
  • Checksum or Hash
  • Nonconformity and corrective-action records
  • Retest results
  • Classification society or shipyard witness records

With this structure, the reviewer can first determine the overall status from the Matrix and then move progressively to the necessary design documents and test results. It is easier to review and manage changes than when all material is placed in one oversized document.

6The Product Description Should Describe the Verification Target, Not Serve as a Product Brochure

The Product Description should give priority to information needed for conformity verification rather than to product benefits or general features.

At a minimum, it should address the following.

  • The product's purpose and onboard functions
  • The product's major components
  • The product Baseline and applicable Models
  • Major Hardware and Software Architecture
  • The product's internal functional structure
  • Connections to external systems
  • User types and maintenance methods
  • Software Update and Backup methods
  • Whether remote access is included
  • Product boundaries and external dependencies
  • Overview of major security functions
  • Items excluded from the approval or verification scope

For example, it is not sufficient to state that "the Machinery Monitoring System monitors the condition of machinery equipment." The product's actual role and potential impact should be described more specifically.

"This system collects operating data and Alarm information from Sensors and PLCs in the Engine Room and displays them on the Operator Station. It does not transmit control commands to upper-level systems during normal operation; however, users with administrator privileges can modify Alarm setpoints and communication settings through the Engineering Station. The system is connected to the vessel Automation Network via Ethernet, and remote access is disabled by Default."

A description of this kind enables the product's functions, access privileges, Interfaces, and potential impact of compromise to be assessed together.

7The Hardware/Software Inventory Should Be the Common Reference Point for the Product Baseline and Evidence

Part 6 addressed the components of the product Baseline. This section therefore focuses on how the Inventory should be linked to other Evidence rather than repeating what the Inventory should contain.

Each Inventory item should be assigned a unique identifier. For example, a Server may be identified as HW-001, a Switch as HW-005, an Application as SW-001, and PLC Firmware as FW-003. Using the same identifiers in the Network Diagram, Interface List, vulnerability review records, and test procedures improves traceability across documents.

For example, the following links can be established.

  • HW-005: Internal managed Switch
  • SW-012: Firmware installed on HW-005
  • IF-007: Interface between HW-005 and the vessel's upper-level Network
  • PPS-014~018: Ports, Protocols, and Services permitted on IF-007
  • CFG-009: Hardening settings for HW-005
  • TC-NW-04: Test confirming that unnecessary management Services are disabled
  • VR-023: Known-vulnerability review result for SW-012

This structure makes it easy to identify the Interfaces, settings, and tests associated with a particular component. The Inventory then becomes a common reference point for the Evidence Package rather than merely an asset list.

8The Network Diagram and Interface List Serve Different Purposes

A Network Diagram provides an intuitive view of the overall connection structure and security boundaries, but becomes difficult to read if every communication detail is placed in a single drawing. Conversely, an Interface List is well suited to recording detailed information but does not show the overall structure at a glance.

The roles of the two documents should therefore be distinguished as follows.

Document Primary Purpose Information to Include
Network Diagram Visual confirmation of components, connections, and boundaries Major equipment, Network Segments, Zones, connections, Gateways, Firewalls, and remote access paths
Interface List Confirmation of detailed communication conditions and responsibilities for each connection Source, Destination, direction, Port, Protocol, Service, data, authentication, encryption, and responsible party
Port, Protocol and Service List Confirmation of the technical basis and minimization of permitted communications Port number, Protocol, Service, purpose, necessity, activation conditions, and whether it can be disabled

For example, if the Diagram shows only a connection labeled "Engineering Station ↔ PLC Network," the Interface List should provide the following details.

  • The Engineering Station and target PLC
  • Communication direction
  • Protocols and Ports used
  • Whether the connection is permanent or used only during maintenance
  • The account authorized to download Logic
  • Authentication or connection approval method
  • Procedure for terminating the connection after use
  • Impact if the connection fails or is misused

The drawing should show the structure, while the list should substantiate the communication conditions within that structure.

9Security Functions Should Be Described by Their Actual Applied State, Not Merely by Whether They Are Supported

A feature that the product technically supports may differ from the feature actually applied to the delivered Configuration. Evidence should therefore distinguish between "supported" and "applied."

For example, the following statement describes only a product capability.

"The product supports Password Policy configuration."

Conformity Evidence should describe the actual applied state, including the following.

  • Minimum Password length
  • Whether complexity requirements are applied
  • Conditions requiring a change of the initial Password
  • Number of permitted failed login attempts
  • Account lockout or delay period
  • Authority to change Passwords
  • Exceptions for Service accounts
  • Method for verifying the setting values
  • Test Cases used to verify the settings

Even if the product supports multiple setting values, its security state is not established until the actual delivery values have been defined. The Hardening Guide should do more than explain the available settings; it should specify the baseline values to be applied to the approved Baseline or project supply configuration.

10The Hardening Guide Should Distinguish Mandatory Settings from Manufacturer Recommendations

A Hardening Guide may contain many security settings, but they do not all have the same importance or responsible party. Classifying them as follows makes the Guide easier to use during installation and handover.

Category Meaning Example
Mandatory Setting that must be applied to the approved Baseline Changing Default credentials and disabling unnecessary Telnet
Project-Defined Setting determined by the project according to the vessel Network and operating conditions IP address, central Log Server, and NTP Server
Conditional Setting applied when a particular function is used MFA and connection logging when Remote Access is enabled
Recommended Recommended for stronger security, but subject to agreement on application Extended Log retention period
Not Applicable Setting that does not apply to the product architecture Wireless setting for a product without a Wireless Module

For example, if remote access is disabled by Default, it is not enough to state that "remote access is not used." The Guide should explain whether the related Services and Ports are disabled, who is authorized to activate them, and what additional controls are required if remote access is requested for a project.

The Hardening Guide should also be linked to the installation Checklist. Even when the Guide specifies the required settings, Evidence is still insufficient if there is no record confirming that they were applied after installation to the delivered Configuration.

11The Manufacturer's Internal Procedures Cannot Substitute for Product Functionality

The manufacturer's internal procedures may provide important Evidence for requirements such as vulnerability management, Software Updates, account management, and remote support. A procedure alone, however, cannot substitute for conformity of the product functionality.

For example, even if the manufacturer has a procedure stating that "remote access may be performed only after approval," the procedure is not sufficient if the product remains in the following state.

  • The Remote Access Service runs continuously
  • Access is possible through a shared account
  • Connection start and end times are not recorded
  • There is no way to terminate access immediately at the site
  • A temporary account remains after the connection ends

In this case, procedural and technical controls are both required. The procedure should define who may perform which actions and under what conditions, while the product functions and settings should enforce the procedure or provide a means of verifying compliance.

Conversely, some activities—such as vulnerability advisories and customer notifications—cannot be performed through product functionality alone. These activities require procedure Evidence covering the following.

  • Sources used to collect vulnerability information
  • Person responsible for impact assessment
  • Criteria for determining applicability to each product
  • Severity and response priority
  • Patch development and verification process
  • Criteria and method for customer notification
  • Support period
  • Action records and approval process

The essential point is to distinguish between matters that must be demonstrated through product functionality and those that must be demonstrated through the manufacturer's internal procedures.

12Conditions and Responsibilities Should Be Defined for Controls That Depend on the Vessel-Wide Security Architecture

Some requirements cannot be satisfied entirely by the equipment product and may need to be combined with the vessel's Network design, common security equipment, or operating procedures. Labeling these matters simply as "shipyard Scope" leaves the responsibility boundary unclear.

At a minimum, the following information should be recorded for each external dependency.

  • Function provided by the product
  • Control to be provided on the vessel side
  • Connection Interface and technical conditions
  • Party responsible for configuration
  • Items to be confirmed after installation
  • Integration test method
  • Impact if the conditions are not satisfied
  • Party responsible for final approval or acceptance

For example, suppose the product can transmit Security Logs through Syslog, while the central Log Server is supplied by the shipyard. The Evidence may be divided as follows.

  • Equipment manufacturer: Security Events that can be generated, Log Format, transmission Protocol, configuration method, and transmission test
  • Shipyard or System Integrator: Receiving Server, Network path, storage capacity, retention period, and access privileges
  • Integration test: Confirmation that Events generated by the product are received correctly by the central Server and contain accurate time and equipment identification information

This allocation clarifies the boundary between product-level Evidence and vessel integration testing.

13Test Evidence Should Include the Test Conditions as Well as the Result

Recording only "Pass" in a test result table does not make it possible to determine whether the result is valid. Test Evidence should include at least the following information.

  • Product under test and Baseline ID
  • Hardware, Software, and Firmware Versions
  • Test date and location
  • Tester and witnesses
  • Test environment and Network Configuration
  • Pre-test configuration state
  • Tools and Versions used
  • Test Procedure and Test Case ID
  • Actions performed
  • Expected result and acceptance criteria
  • Actual result
  • Screenshot, Log, or Configuration Record
  • Deviations arising during the test
  • Failed items and corrective actions
  • Whether retesting was performed and the final result
  • Whether the original state was restored after testing

For example, a failed-login restriction test should verify the following rather than merely record "access denied when an incorrect Password was entered—Pass."

  • 1Enter an incorrect Password for the test account the configured number of times.
  • 2Confirm that further login attempts are restricted after the configured number of failures.
  • 3Confirm that access is denied even with the correct Password during the restriction period.
  • 4Confirm that the failed Events and account status changes are recorded in the Log.
  • 5Verify that the Events are visible on the administrator screen.
  • 6Confirm that normal access is restored after the restriction period expires or the administrator releases the account.

Test conditions and expected results must be this specific if another tester is to reproduce the same procedure.

14Screenshots and Logs Are Difficult to Use as Evidence Without Context

Screenshots are easy to obtain and are therefore used frequently, but the screen alone may not identify the test target, conditions, or result.

Valid Screenshot Evidence should be linked, where practicable, to the following information.

  • Evidence ID
  • Related Test Case ID
  • Product or equipment identification
  • Application or Firmware Version
  • Date and time captured
  • Action performed
  • Result being verified
  • Explanation of the relevant area of the screen
  • Whether sensitive information has been masked
  • Location where the original file is retained

The same principle applies to Logs. If hundreds of lines of raw Log data are attached without explanation, the reviewer must locate the relevant Event independently. The Evidence should identify the Event location, Timestamp, Event ID, user, Source equipment, and basis for the result.

For example, Log Evidence for a remote access termination test should link the following Events.

  • Time of access approval
  • Time of successful user authentication
  • Remote Session start time
  • Operator or account information
  • Session end time
  • Remote Service status after termination
  • Confirmation that no temporary account or Session remains

Screenshots and Logs are objective records supporting a test result; they do not replace the Test Procedure or the explanation of how the result was determined.

15Inconsistencies Between Documents Can Create a Greater Credibility Problem Than Missing Detail

Even when each document in the Evidence Package is sufficiently detailed, the reliability of the package is weakened if the documents describe different product states.

Typical inconsistencies include the following.

  • The Product Description states that Remote Access is not included, but the Network Diagram shows a Remote Access Gateway
  • The Software Inventory lists Application Version 3.2, but the test results apply to Version 3.1
  • The Interface List permits TCP 443, but the Port, Protocol and Service List does not include it
  • The Hardening Guide requires deletion of the Default account, but that account remains in the FAT results
  • The Backup Procedure states that the OS Image is included, but the actual test restores only configuration files
  • The User and Privilege Matrix states that an Operator cannot modify settings, but the User Manual explains how the Operator can make such changes

These discrepancies may be simple editorial errors, but from the reviewer's perspective they can raise doubts about the actual product Configuration and its management system.

Document review should therefore do more than check spelling and Revision numbers. It should confirm that every document consistently describes the same product Baseline.

16Unmet Requirements and Limitations Should Be Managed Separately Rather Than Concealed

The purpose of an Evidence Package is not to mark every item "Comply" without qualification. Project risk can be reduced by clearly identifying requirements that the current product cannot fully satisfy, matters that depend on external controls, and items requiring further agreement.

The following information should be recorded for unmet or partially satisfied requirements.

  • Related requirement
  • Current state of the product
  • Element that is not satisfied
  • Technical or schedule-related reason
  • Expected security impact
  • Interim measure or compensating control
  • Matter requiring agreement with the shipyard or classification society
  • Product improvement plan
  • Responsible person and target completion date
  • Verification and closure criteria

For example, if a Legacy Controller does not support individual user accounts, it should not be treated as exempt or described as "providing account management." The current state and mitigation should be distinguished as follows.

  • Current state: Only one administrator account is supported
  • Risk: Activities cannot be traced to individual personnel
  • External product control: Install the Controller inside a locked Cabinet and restrict Engineering Station access to authorized personnel
  • Operational control: Require maintenance work approval and retain work records
  • Additional Evidence: Cabinet access controls, Engineering Station account records, and maintenance work records
  • Matter for agreement: Acceptance of the compensating control and the future product improvement plan

Managing limitations in this structured manner enables the classification society and shipyard to assess acceptability, additional actions, and residual risk.

17Evidence Status Should Distinguish Draft, Approved, and Superseded Documents

During a project, several Revisions of the same document may circulate at the same time. The development team may use the latest Version while an earlier Revision has been submitted to the shipyard, and the test team may use a separately amended procedure.

Each item of Evidence should display at least the following information.

  • Document number
  • Document title
  • Revision
  • Date of preparation
  • Author
  • Reviewer and approver
  • Applicable product Baseline
  • Applicable project
  • Document status
  • Description of changes
  • Previous Revision replaced by the document

Document status may vary according to the organization's system, but at least the following states should be distinguished.

  • Draft: Under preparation or review and not available for use as official Evidence
  • Issued for Review: Submitted for review by the classification society or shipyard
  • Approved for Use: Approved for use in testing, production, or delivery
  • As-Built: Reflects the final delivered Configuration
  • Superseded: Replaced by a newer Revision and no longer permitted for use

The validity of the Evidence may need to be reassessed if test results were produced using an unapproved Draft procedure or if a Superseded document was included in the delivery package.

18The Evidence Package Needs Navigation for the Reviewer

As the volume of material grows, it becomes increasingly important not only that each document is well prepared, but also that the reviewer can locate the necessary information efficiently.

The opening section of the Evidence Package should provide the following information.

  • Basic product and project information
  • Product Baseline ID
  • Approval or verification Scope
  • Submission document list and Revisions
  • Relationships among the documents
  • Requirement–Design–Evidence Matrix
  • Major limitations and external dependencies
  • Open items and target completion dates
  • Contact person for each category of inquiry

Consistent file-naming rules should also be applied. For example, the document type, product, document number, and Revision may be identified as follows.

  • CMS-SEC-DD-001_Product-Security-Description_Rev2
  • CMS-SEC-STP-001_Security-Test-Procedure_Rev1
  • CMS-SEC-STR-001_Security-Test-Report_Rev0

By contrast, filenames such as "Final," "Final Revised," "Real Final," or "FAT Revision 2" make it difficult to distinguish the history and valid status of the official submission documents.

Good Navigation does not reduce the volume of documentation, but it can reduce review time and repeated inquiries.

19Reuse of Evidence Requires Confirmation of Applicability, Not Mere Document Copying

Evidence used for Type Approval or a previous project may be reused in subsequent projects. It should not, however, be reused merely by changing the vessel name and date in an existing document.

The following should be confirmed before reuse.

  • Is the product Baseline the same?
  • Are the Hardware and Software Versions within the approval scope?
  • Have any project-specific optional functions been added?
  • Are the Interfaces and communication counterparts the same?
  • Have the same Hardening settings been applied?
  • Have the external dependency conditions changed?
  • Has any change invalidated the existing test results?
  • Are the applicable classification society and project requirements the same?
  • Does the document contain information from the previous project?

For example, if Remote Access was disabled in the previous project and the relevant tests were excluded, but the owner requests Remote Access in a new project, some of the existing Product Description and basic security test results may still be reused. The Remote Access Architecture, approval procedure, Logs, and integration tests, however, must be prepared for the new project.

The key to Evidence reuse is not submitting the same document again, but confirming that the previous substantiation remains valid for the new Product Configuration and project conditions.

20Eight Common Mistakes When Preparing an Evidence Package

  • 1 Treating a Function List as Conformity EvidenceStatements such as "Logging supported," "Backup available," and "Remote Access provided" do not show the actual implementation or applied state.
  • 2 Creating a New Document for Every Requirement and Repeating the Same ContentIf the same product structure and functional description are duplicated across multiple documents, inconsistent content may remain after a change. It is more efficient to maintain common design information in one place and link the relevant Sections to each requirement in the Matrix.
  • 3 Referring to an Entire Document Without Identifying the Relevant LocationRather than stating "refer to the User Manual," specify the document number, Revision, Section, and Figure so that the reviewer can locate the Evidence.
  • 4 Assuming That a Large Number of Screenshots Is SufficientScreenshots do not contain the test conditions, operating steps, or acceptance criteria. They should be accompanied by the applicable Test Case and an explanation of the result.
  • 5 Confusing Product Functionality with the Manufacturer's Internal ProceduresAccount lockout and access denial should be verified through product functionality, whereas vulnerability notification and customer support should be demonstrated through the manufacturer's internal procedures.
  • 6 Labeling an Item Only as the Shipyard's ResponsibilityIf a requirement depends on the vessel-wide security architecture, the product function, vessel-side conditions, and integration test responsibilities should be allocated specifically.
  • 7 Deleting Failed Test Records and Retaining Only the Final Successful ResultTest failures, root-cause analysis, corrective actions, and retest results can provide important Evidence that the product was properly verified.
  • 8 Failing to Update the Evidence After the Product ChangesIf a Software Patch, Switch replacement, or setting change occurs, the affected design documents and test results should be reviewed together.

21In Practice, an Evidence Package Can Be Prepared in the Following Sequence

  • 1Establish the product Baseline and Scope subject to approval or verification.
  • 2Identify the applicable requirements and project-specific submission requirements.
  • 3Prepare the Requirement–Design–Evidence Matrix and determine the applicability of each requirement.
  • 4Allocate the controls for each requirement among product functionality, product Configuration, the manufacturer's internal procedures, and the vessel-wide security architecture.
  • 5Link existing documents and available test results to the Matrix.
  • 6Distinguish items for which no Evidence exists from those for which the existing Evidence is insufficient.
  • 7Align the reference information in the Product Description, Inventory, Network Diagram, and Interface List.
  • 8Develop or update the Hardening, account management, Backup, Update, remote access, and vulnerability management materials.
  • 9Define the verification method and Test Cases for each requirement.
  • 10Perform the tests using a Test Configuration identical to the product Baseline.
  • 11Retain Screenshots, Logs, Configuration records, and Checksums linked to the relevant Test Cases.
  • 12Manage unmet requirements, external dependencies, compensating controls, and project Deviations separately.
  • 13Review consistency of product names, Models, Versions, Interfaces, and setting information across documents.
  • 14Prepare the submission document list and Navigation.
  • 15When a classification society or shipyard Comment is received, update the related requirements, design documents, tests, and product-change impact together.

The central principle of this sequence is not to prepare all documents first and link them to the requirements at the end. The requirements, product design, settings, and test results should be managed within the same structure from the outset.

22Conclusion: Good Evidence Enables the Reviewer to Reach the Same Conclusion

In UR E27 compliance work, insufficient Evidence does not simply mean that too few documents have been prepared. It means that conformity is difficult to demonstrate because the following links cannot be confirmed, even if the product contains the relevant function.

Requirement → Applicability → Specific Control → Design Document → Product Configuration → Test Procedure → Test Result → Delivery Configuration

A well-structured Evidence Package enables the reviewer to follow this chain and obtain consistent answers to the following questions.

  • Which product and Version are being reviewed?
  • Which requirements apply?
  • What controls have been implemented in the product?
  • How are they configured in the actual delivery Configuration?
  • Under which conditions and procedures were they tested?
  • Which objective records demonstrate whether the acceptance criteria were met?
  • Which elements depend on controls outside the product?
  • How are unmet or partially satisfied requirements managed?
  • Can the existing Evidence still be used after a product change?

A well-structured Evidence Package reduces the need to repeat the same content across multiple documents. The Product Description explains the product structure and functions, while the Inventory identifies the product Baseline. The Network Diagram and Interface List show the connections and boundaries. The Hardening Guide and management procedures define the applicable settings and responsibilities, while the Test Procedure and test results demonstrate that the controls actually operate. The Requirement–Design–Evidence Matrix links these materials to the applicable requirements.

An equipment manufacturer should therefore prepare an Evidence system that meets the following conditions rather than simply producing as many documents as possible.

  • 1It is directly linked to the product Baseline.
  • 2Implementation can be traced for each requirement.
  • 3The design, Configuration, and test results are consistent.
  • 4The responsibility boundary between the product and external security controls is clear.
  • 5Unmet requirements and limitations are managed transparently.
  • 6When a change occurs, the affected Evidence can be identified.
  • 7The reviewer can reach the same conformity conclusion without excessive assumptions.

The statement that "the function exists" is only the starting point for verification. It becomes verifiable Engineering Evidence only when the manufacturer can link the function to the product Baseline in which it is implemented, the settings through which it is applied, and the tests through which its operation has been confirmed.

The next article will examine in greater detail the Test Procedures and test results that generate the greatest amount of rework within an Evidence Package.

Part 8 will address the question, "How can a functional description in a manual be converted into a reproducible Test Procedure?" It will examine how to define Test Case preconditions, test steps, expected results, acceptance criteria, failure conditions, restoration steps, and objective test records, and how to verify not only normal operation but also the failure, bypass, and recovery behavior of security controls.

Next Article — Article 8

How Can a Functional Description in a Manual Be Converted into a Reproducible Test Procedure?

Article 8 will examine how to define Test Case preconditions, test steps, expected results, acceptance criteria, failure conditions, restoration steps, and objective test records, and how to verify not only normal operation but also the failure, bypass, and recovery behavior of security controls.

Series Navigation — UR E27 Strategies for Marine Equipment Suppliers (12 Articles)
▶ NOW How Can a Statement That a Function Exists Be Converted into Verifiable Evidence?
Article 8 How Can a Functional Description in a Manual Be Converted into a Reproducible Test Procedure?
Article 9 What Must Be Demonstrated During Production, FAT, and Delivery?
Article 10 What Should the Equipment Supplier, Shipyard, Classification Society, and CRSI Each Do?
Article 11 What Should You Ask the Classification Society and Shipyard — and When?
Article 12 How Should a Realistic UR E27 Certification Schedule and Project Organization Be Structured?
#MaritimeCybersecurity #IACS #URE27 #EvidencePackage #Traceability #TypeApproval #MarineEquipmentSuppliers #CRSI #Maritime40 #BlueHorizonist
Blue Horizonist
Blue Horizonist
Cybersecurity Consultant · ISP · ISMP

IT/OT Integrated Cybersecurity specialist with expertise in IACS UR E26/E27 compliance, N2SF, Cybersecurity Strategy & Governance, BPR, and Digital Transformation. Former IT Consultant at KPMG (2019–2022). M.S. Information Systems, University of Maryland, Robert H. Smith School of Business.

⚓ Join the ShipPaulJobs Community

Join →
Share
LinkedIn Facebook X (Twitter) WhatsApp Telegram Reddit WeChat Copy Link

Comments

Post a Comment

Top Ranked · All Posts

Popular Posts