How Should UR E27 Requirements Be Interpreted and Allocated to Our Product?
Article 4 of a 12-Part Series on UR E27 Strategies for Marine Equipment Suppliers
※ The product, system, and project examples described in this article are illustrative examples created to explain how UR E27 requirements should be interpreted and allocated.
The previous article examined how to determine whether a product falls within the scope of UR E27. Once applicability has been established, the equipment manufacturer must answer the next question: “What security functions and measures must be incorporated into our product to satisfy each UR E27 requirement?”
Understanding the requirements of the specification and translating them into an actual product design are two different tasks. For example, even when UR E27 requires user authentication, access restriction, security event logging, or secure recovery, these requirements are not necessarily satisfied through a single software function. Some requirements must be implemented as inherent product functions, while others may be addressed through secure product configuration. Still others can only be satisfied by combining the manufacturer's development and service procedures with the vessel-wide security architecture established by the shipyard.
A requirements analysis should therefore go beyond marking each requirement as “compliant” or “non-compliant.” At a minimum, it should answer the following four questions:
- 1What security functions or measures have been incorporated into the product to address this requirement?
- 2Where are those functions or measures implemented — in the product functionality, product configuration, manufacturer's internal procedures, or vessel-wide security architecture?
- 3Who is responsible for designing, implementing, and operating those functions or measures?
- 4What evidence demonstrates that the requirement has been properly addressed?
This article explains how to translate UR E27 requirements into detailed, actionable, and verifiable items, and connect them to product design, responsible parties, and supporting evidence through a Requirement–Design–Evidence Matrix.
1. One Requirement in the Specification Does Not Necessarily Correspond to One Product Function
UR E27 is not written around the product architecture or development practices of any particular manufacturer. A single requirement in the specification may therefore need to be addressed through several product functions, settings, and procedures. Consider the following high-level requirement:
If this statement is simply copied into a requirements list and answered with “Password function provided,” it does not adequately explain how access to the product is actually restricted. The following matters must also be examined:
- What access paths into the product exist?
- Are users identified and authenticated through each access path?
- Are general-user and administrator privileges separated?
- Can default accounts be changed or disabled?
- If shared accounts must be used, what is the justification and what compensating measures apply?
- Who creates, modifies, and deletes accounts?
- Is there a function that restricts repeated authentication failures?
- Are maintenance accounts activated only when required?
- Are login activities and privilege changes recorded in logs?
- If access restrictions must be lifted during an emergency, what approval procedure applies?
A single sentence in the specification ultimately expands into several design and verification items at the product level. Rather than immediately mapping one sentence to one product function, the manufacturer should ask:
Answering this question is the starting point of requirements analysis.
2. Requirements Should Be Divided into the Smallest Independently Verifiable Units
Using a high-level requirement exactly as written in the specification can make the design description and test method ambiguous. To prevent this, each requirement should be divided into the smallest units that can be independently verified — often called Atomic Requirements. For example, the high-level requirement for user access control may be divided as follows:
- Users are authenticated through every logical access path.
- Privileges are separated by individual user or role.
- General users are prevented from performing administrative functions.
- Default credentials are changed before installation or delivery.
- Unused accounts are disabled or deleted.
- Further access is restricted after repeated failed login attempts.
- Account creation, deletion, and privilege changes are recorded.
- Maintenance accounts are activated only under approved conditions.
Each detailed requirement should focus on one subject and one verifiable action. Combining several security functions in a single statement makes it difficult to determine the actual level of compliance:
This statement contains four different functions: authentication, privilege management, log generation, and notification. Depending on the product, authentication may be supported while notification is not; logs may be generated but not transferable to a central system. The statement should therefore be divided as follows:
- 1The system authenticates authorized users.
- 2The system restricts access to functions according to user roles.
- 3The system records failed login attempts.
- 4The system makes generated security events available to an administrator or external system.
Breaking the requirement down in this manner allows the applicability, implementation method, evidence, and compliance status of each item to be assessed independently.
3. The Purpose of the Requirement and the Product's Actual Behavior Must Be Considered Together
Before applying a UR E27 requirement to a product, the manufacturer must understand what the requirement is intended to protect or prevent. For example, the purpose of a requirement to restrict unnecessary ports, protocols, and services is not simply to produce a list of ports — its purpose is to reduce unnecessary access paths that could be exploited by an attacker. Both the underlying purpose of the requirement and the product's actual behavior must therefore be examined.
- Are externally accessible paths minimized?
- Is unauthorized communication blocked?
- Are essential and unnecessary communications distinguished?
- Can changes to communication settings be identified?
- Which ports and protocols are actually used?
- Which services are enabled by default when the OS is installed?
- Which communications are essential for the product's functions?
- Can unused services be disabled?
- Do communication targets or ports vary by project?
- Do existing control functions continue to work after communications are restricted?
If the purpose of the requirement is understood without examining the product's actual behavior, the result may be nothing more than an abstract policy document. Conversely, if the review only lists the ports and services currently in use, every communication path may simply be declared “necessary for product operation.”
Requirements analysis must therefore connect the intent of the specification with the product's actual behavior.
4. Requirements Can Be Allocated Across Four Implementation Areas
UR E27 requirements applicable to a product will generally be addressed in one of the following four areas, or through a combination of two or more of them.
Security functions performed directly by software, firmware, or hardware incorporated into the product.
Examples: user authentication, role-based privilege restrictions, security log generation, integrity verification of software/files, automatic session termination, backup and restore, blocking unauthorized communications, transitioning to a safe state after a failure.
Security measures that rely on existing product capabilities but must be securely configured before delivery or during installation.
Examples: changing default passwords, disabling unnecessary accounts, stopping unused services, registering only permitted IPs/ports, configuring log capacity and retention, setting the auto screen-lock interval, restricting USB use, disabling remote access by default.
Ongoing management activities that cannot be completed through product functions alone and must be performed by the equipment manufacturer.
Examples: collecting and assessing vulnerability information, developing and distributing security updates, notifying customers, managing the security support period, controlling access to the development environment, managing software changes/configurations, incident support, managing service-engineer accounts.
Security measures provided across the vessel by the shipyard or system integrator rather than by an individual product.
Examples: firewalls between zones, vessel-wide remote access gateway, central user authentication, central log collection, network IDS, vessel-wide time synchronization, network redundancy, vessel-wide backup and recovery plan.
These four areas are not alternatives from which only one must be selected — they often need to work together. For example, if the product cannot generate security logs, there will be no useful information for a central log server to collect. Conversely, even if the product generates logs, they may be of limited value for vessel-wide incident analysis if there is no central transmission path or time synchronization.
5. Responsibility Should Be Allocated to the Party That Can Actually Implement the Measure
Responsibility should not be assigned according to who prepares the document. It should be assigned according to who can actually change and maintain the relevant function or configuration. The following questions can help identify the responsible party:
- Which organization can modify the source code for the function?
- Which organization defines and applies the security configuration?
- Who manages the configuration after delivery?
- Who creates and deletes user accounts during vessel operation?
- Who configures the firewall rules on the upper-level network?
- Which organization receives and reviews security events?
- Who performs recovery activities following a failure or compromise?
- Who obtains and verifies updates for third-party products?
For example, the type and format of logs generated within the product will generally be determined by the equipment manufacturer. However, the network path for transmitting those logs, the receiving server address, and the overall retention period may need to be agreed with the shipyard or shipowner. Similarly, the manufacturer may provide the backup file format and restore function, while the location in which backup files are stored onboard and the frequency of regular backups may be determined by the shipowner's or shipyard's operational policies.
Responsibility should therefore be allocated according to actual design, configuration, and operational authority — not according to who is assigned to prepare the documentation.
6. “Partially Satisfied by the Product” Is Different from “Fully Satisfied by the Product Alone”
A common mistake when preparing a requirement matrix is to declare an entire requirement “fully compliant” merely because the product includes a related function. Consider a product that supports external syslog transmission — this capability alone does not satisfy every requirement associated with centralized security monitoring. The following conditions must also be confirmed:
- Does the product generate the security events required for security analysis?
- Does each event include the user, time, target, and action performed?
- Can the generated events be transmitted externally?
- Does the vessel network permit the required transmission path?
- Is a central log server available to receive the events?
- Are the product and central server time-synchronized?
- Can a log transmission failure be detected?
- Who reviews the collected logs and determines whether abnormal activity has occurred?
Of these items, log generation and external transmission should generally be supported by the product. The network path and central log server should be established through the vessel's integrated design, while log review should be defined in the procedures of the shipowner or operating organization. Instead of recording only “Syslog supported — Compliant,” the matrix should provide a more precise explanation:
This wording identifies both the scope satisfied by the product and the additional measures to be provided by the shipyard or shipowner.
7. Case 1: How Can User Access-Control Requirements Be Allocated?
Consider a Cargo Monitoring System supplied with the following components: a main server, two operator workstations, a PLC, a managed Ethernet switch, an engineering laptop, and an interface to the shipyard's integrated remote access gateway. The high-level requirement that “only authorized users shall be permitted to access the system” may be allocated as follows:
| Detailed Requirement | Implementation Area | Primary Responsibility | Required Evidence |
|---|---|---|---|
| Separate operator and administrator privileges | Product functionality | Equipment manufacturer | Privilege matrix, screen captures, test results |
| Change the default administrator password | Product configuration | Equipment manufacturer | Hardening checklist, installation record |
| Manage user accounts during vessel operation | Operational procedure | Shipowner / operator | Account-management procedure, approval records |
| Obtain prior authorization for engineering laptop use | Joint procedure | Manufacturer & shipowner | Maintenance procedure, work authorization |
| Authenticate remote-access users | Vessel-wide security architecture | Shipyard / integrator | Remote access design document, gateway test results |
| Restrict remote-user privileges within the product | Functionality & configuration | Equipment manufacturer | Account design document, configuration record |
| Record identity and start/end time of remote work | Functionality & vessel architecture | Shared responsibility | Product logs, gateway logs, integration test results |
| Immediately terminate remote access during an emergency | Vessel architecture & product configuration | Shared responsibility | Termination procedure, functional test results |
The important point is that responsibility for remote access has not been assigned entirely to either the shipyard or the equipment manufacturer. The shipyard may provide the external access gateway and vessel network path — the equipment manufacturer must still restrict which accounts can be used to access the product and which functions those accounts can perform.
A single high-level requirement may therefore need to be allocated across several components and organizations.
8. Case 2: The Presence of a Backup Function Does Not Guarantee Recovery
If the product manual states that “backup is supported,” the manufacturer may assume that the recovery requirements have been satisfied. It is nevertheless necessary to determine exactly what is backed up and to what extent the system can be restored. For example, a system may contain: PLC logic, HMI application, user accounts and privileges, network settings, operational parameters, alarm settings, historical data, OS image, and third-party software settings. If the product's backup function only exports historical data to an external file, it cannot reasonably be regarded as a backup that enables the system to be restored to its normal operating state following a failure.
Recovery-related requirements can be divided as follows:
- 1Identify the software and configuration information required for system recovery.
- 2Create backup files containing the required information.
- 3Manage the version and integrity of each backup file.
- 4Protect backup files against unauthorized modification.
- 5Restore backup files to a damaged system.
- 6Confirm that essential operational functions work correctly after restore.
- 7Retain the installation images and tools required for recovery.
- 8Document the recovery procedure and assign responsible personnel.
Responsibility for these activities may also be divided: backup/restore functions sit with product functionality; backup scope and method with the manufacturer's design and manuals; onboard storage location with the vessel integration design; regular backup execution with the shipowner's operational procedures; restore-function testing with the manufacturer's internal testing and FAT; and long-term retention and version management as a shared responsibility between manufacturer and shipowner.
Breaking the requirement down in this way makes clear that “a backup button exists” and “the system can be restored to a normal operating state” are not the same statement.
9. Case 3: Vulnerability Management Depends More on Organizational Capability Than Product Functionality
Not every requirement can be verified through a product screen or software menu. Vulnerability and security-update management is an area in which the equipment manufacturer's organizational capability is particularly important. Even if a product supports the installation of security updates, it may be difficult to demonstrate its continuing cyber resilience unless the manufacturer performs the following activities:
- Collect vulnerability information for own products and third-party components
- Analyze the impact of disclosed vulnerabilities on the product
- Identify affected versions and configurations
- Assess risk and remediation urgency
- Develop a patch or mitigating measure
- Perform regression and security testing
- Notify affected customers of the vulnerability and corrective action
- Distribute the update package securely
- Communicate end of security support and available alternatives
For example, assume that a new CVE is disclosed for a commercial operating system used in the product. The manufacturer should not simply forward the OS vendor's patch link to the customer — it must first determine whether the patch affects the product's application, drivers, PLC communications, or HMI behavior.
Vulnerability-management responsibilities may be allocated as follows: update installation capability sits with product functionality; definition of applicable versions and conditions with product design and configuration management; vulnerability impact assessment and patch verification with the manufacturer's internal procedures and quality process; customer notification with the service procedure; approval and scheduling of onboard deployment with the shipowner and shipyard's operational procedures; and actual installation with a shared responsibility based on contractual conditions.
In this case, the primary evidence is not a screenshot from the product. It consists of vulnerability-management procedures, impact-assessment results, test records, customer notices, and update histories.
10. When Relying on the Vessel-Wide Security Architecture, the Required Conditions Must Be Clearly Defined
It is difficult for an individual product to satisfy every security requirement independently. Reliance on vessel-wide security measures is therefore often necessary and can be an appropriate design approach when the respective roles and conditions are clearly defined. However, simply recording “Provided by Shipyard” in the requirement matrix is not sufficient — the equipment manufacturer must specify the conditions required at the interface between the product and the vessel.
Dependencies on the vessel-wide security architecture must be translated into specific interface requirements so that the shipyard can incorporate them into the vessel design and verify them during integration testing.
11. Not Applicable, External Dependency, and Compensating Control Must Be Managed Separately
The following three statuses should be clearly distinguished in the requirement matrix.
Consider a legacy controller that does not support individual user accounts. This should not simply be classified as N/A — a combination of compensating controls may instead be considered:
- Protect the cabinet containing the controller with a lock
- Permit only an approved, dedicated engineering laptop
- Require individual user authentication on the laptop
- Apply a pre-authorization procedure
- Require supervision by the responsible person during the work
- Perform a backup before and after configuration changes
- Maintain a separate work record of all changes
- Disable or block the service port after the work is completed
A compensating control does not mean that the original requirement has disappeared. It recognizes the product's technical limitations and reduces the risk through other means. Approval from the shipyard or classification society may therefore be required together with the supporting risk analysis.
12. What Should Be Recorded in a Requirement–Design–Evidence Matrix?
A Requirement–Design–Evidence Matrix is not merely a list containing copied sentences from the specification. It is a management tool that connects each requirement to the method used to address it, the responsible party, and the evidence used to demonstrate conformity. In practice, the following fields should be considered:
| Field | Information to Record |
|---|---|
| Requirement ID | Requirement number in UR E27 or the applicable classification rule |
| Source Requirement | Original requirement or its essential meaning |
| Atomic Requirement | Requirement divided into an independently verifiable unit |
| Security Objective | Security purpose to be achieved by applying the requirement |
| Applicability | Applicable, conditionally applicable, or N/A |
| Applicability Rationale | Specific basis for determining applicability or exclusion |
| Target Component | Hardware, software, or interface to which the requirement applies |
| Implementation Type | Product functionality, configuration, internal procedure, or vessel-wide architecture |
| Design Implementation | Function, configuration, or procedure actually implemented |
| Responsible Party | Party responsible for design, configuration, operation, and verification |
| External Dependency | Conditions to be provided by the shipyard or an external system |
| Verification Method | Inspection, Analysis, Demonstration, or Test |
| Evidence | Drawings, design documents, configuration records, procedures, and test results |
| Gap Status | Compliant, partially compliant, non-compliant, or requiring further confirmation |
| Required Action | Development, configuration change, documentation, testing, or stakeholder consultation |
| Owner & Due Date | Person responsible for the action and target completion date |
| Configuration Reference | Applicable model, version, and baseline |
| Approval Status | Status of internal review, shipyard consultation, and classification confirmation |
It is not necessary to create an excessively complex matrix from the beginning of every project. The following basic relationship must nevertheless be maintained:
Requirement → Applicable Target → Implementation Method → Responsible Party → Verification Method → Evidence
If this relationship is broken, it becomes difficult to explain consistently how the requirements have been satisfied, regardless of how many documents are submitted.
13. A Practical Example of Converting One Requirement into a Matrix
Consider a high-level requirement stating that “security-relevant activities shall be recorded,” applied to a Cargo Monitoring System. The security events to be recorded within the product should first be defined: successful and failed logins, administrator configuration changes, user-account creation and deletion, user-privilege changes, software updates, start and end of remote access, changes to log settings, and changes to system time information. The implementation method and evidence for each item can then be connected as follows:
| Detailed Requirement | Target | Method | Responsibility | Verification | Evidence | Status |
|---|---|---|---|---|---|---|
| Record failed login attempts | Main Server, HMI | Application security log | Manufacturer | Test | Log sample, test record | Compliant |
| Record admin config changes | Main Server | User ID + before/after values | Manufacturer | Test | Screenshot, log | Partial |
| Track PLC logic changes | PLC | Engineering-tool change history | Manufacturer | Demonstration | Tool history, procedure | TBC |
| Consistent timestamps on all events | Entire system | Sync with vessel NTP server | Shared | Integration test | Network config, test results | External dep. |
| Transmit events to central log server | Main Server | Syslog transmission | Shared | Integration test | Interface spec, received logs | Design TBD |
| Restrict permission to delete logs | Main Server | Admin-only deletion permission | Manufacturer | Test | Privilege matrix, test results | Compliant |
| Define log retention period | Server + storage | Local capacity + operating policy | Shared | Analysis | Capacity calc, operational policy | Not defined |
This table reveals several important points. First, generating certain logs within the product does not mean that all related requirements have been satisfied. Second, the events that can be recorded may differ between components such as the PLC and Server. Third, central transmission and time synchronization may depend on the vessel's integrated design. Fourth, the log retention period must consider both the product's storage capacity and the shipowner's operating policy. Finally, the matrix distinguishes whether an outstanding issue requires software development, product configuration, an operational procedure, or consultation with the shipyard.
The practical purpose of the matrix is to connect product functionality, responsibility, and evidence in a single traceable flow.
14. The Matrix Can Also Be Used to Analyze the Impact of Configuration Changes
A Requirement–Design–Evidence Matrix is not used only when preparing the initial approval documentation. It can also provide a basis for determining which requirements and evidence must be reviewed when the product or project configuration changes. Assume, for example, that the operating system of the Main Server is changed. The matrix can be used to assess the following impacts systematically:
- Does the user-authentication method change?
- Can existing hardening settings apply to the new OS?
- Does the list of unnecessary services change?
- Do the types/storage of security logs change?
- Is the new OS compatible with antivirus/whitelisting software?
- Must a new backup image be created?
- Can the existing test results still be accepted?
- Is the new OS within the existing Type Approval / verification scope?
- Must user, installation, and recovery manuals be revised?
Without a matrix, an OS change may be treated as a simple configuration change requiring only an update to the BOM or version list. With a matrix, the manufacturer can trace how that single change affects security functions, documents, and tests.
The Requirement–Design–Evidence Matrix can therefore serve both as a checklist for confirming compliance and as a tool for assessing the impact of product changes.
15. Five Common Errors in Requirements Analysis
A response such as “Access Control — Complied” does not explain which access paths are restricted or how those restrictions are implemented. High-level requirements should be divided into detailed items that can be independently verified.
Even when the required function is present, it may be difficult for the classification society or shipyard to verify it objectively if no design description, configuration standard, test procedure, or test result is available. The existence of a function and the availability of evidence must be managed separately.
Statements such as “Firewall by Yard” or “Remote Access by Shipyard” do not tell the shipyard which communications must be permitted or which interfaces must be implemented. The manufacturer must also provide specific interface requirements.
The absence of a particular product function does not mean the corresponding requirement is not applicable. The manufacturer must distinguish between a genuinely non-applicable requirement, reliance on an external measure, current non-compliance, and the need for a compensating control.
Actual implementation information is distributed across the development, design, quality, production, and service organizations. The certification team may consolidate the overall matrix, but the technical content of each item must be confirmed and owned by the organization that actually controls the relevant function or procedure.
16. Not Every Requirement Needs to Be Finalized from the Beginning
The initial matrix may contain unresolved items. The important point is not to conceal them or classify all of them simply as “To Be Confirmed.” Instead, they should be categorized according to the required confirmation and action:
- Items requiring internal technical review
- Items requiring a product-development decision
- Items requiring confirmation from a third-party supplier
- Items dependent on finalization of the shipyard interface
- Items requiring interpretation or approval by the classification society
- Items requiring a compensating control and subsequent approval
For example, even if the address of the central log server has not yet been determined, the product's required protocol, event types, and communication direction can still be defined. Similarly, even if the supplier of the remote access gateway has not been selected, the product-level accounts and privileges, remotely accessible services, and emergency disconnection method can still be established.
The overall analysis should not be delayed simply because external conditions have not yet been finalized. Product requirements that can already be determined should be managed separately from conditions requiring later agreement with the shipyard or classification society.
17. The Following Sequence Is Effective in Practice
Requirements analysis and allocation can be performed in the following sequence:
- 1Collect the applicable UR E27 and classification requirements.
- 2Understand the purpose and intent of each requirement.
- 3Divide high-level requirements into detailed, independently verifiable items.
- 4Identify the components and interfaces to which each detailed requirement applies.
- 5Classify each requirement under one of the four implementation areas.
- 6Assign responsibility according to actual design and operational authority.
- 7Describe the implemented functions and settings and any external dependencies.
- 8Select an appropriate verification method — Inspection, Analysis, Demonstration, or Test.
- 9Link the available design documents, configuration records, test results, and procedures.
- 10Register non-compliant items, matters requiring further confirmation, and corrective actions.
- 11Track matters requiring consultation with the shipyard or classification society separately.
- 12When the product baseline changes, reassess the impact on related requirements and evidence.
The result is more than a list of requirements. It becomes a common management basis that tells the development team which functions must be implemented, the quality team which items must be verified, the documentation team which evidence must be prepared, and the sales team which conditions and lead times must be reflected in the quotation.
18. Conclusion: A Requirement Is Complete Only When It Is Linked to Responsibility and Evidence
Applying UR E27 requirements to a product is not a matter of copying sentences from the specification into the product manual. The following elements must be connected for each requirement:
- What is the requirement intended to protect?
- What functions and configurations have been incorporated into the product to address it?
- Which components and interfaces does it apply to?
- Is it satisfied through product functionality, configuration, internal procedures, or vessel-wide architecture?
- Who designs, configures, and operates the relevant measures?
- How will proper implementation be verified?
- Which documents and test results will demonstrate conformity?
- What remains incomplete, and who will complete it by what date?
Only when these relationships have been established does the statement that “the product satisfies the requirement” become a verifiable engineering statement. A Requirement–Design–Evidence Matrix is not intended to create a long list of requirements copied from the specification — it is a management tool that connects product security functions, design responsibilities, external dependencies, and evidence in a single traceable flow.
Using the matrix, an equipment manufacturer should be able to distinguish among:
- 1Items that the current product already satisfies and can demonstrate
- 2Items requiring development, configuration changes, documentation, or additional testing
- 3Items requiring agreement with the shipyard or classification society regarding responsibility and implementation
Once these distinctions can be made, the equipment manufacturer can explain the product's actual level of readiness objectively.
Understanding the product's level of compliance does not automatically determine the appropriate certification route. Even for the same product, the method of demonstrating conformity may differ depending on repeat-supply potential, the extent of customer-specific modifications, the stability of the product baseline, and the maturity of the available evidence.
Which should we choose — TA, SoC, or SoF?
Moving beyond a simple comparison of certificate names, Article 5 will explain how to select an appropriate conformity-demonstration route based on repeat-supply potential, the extent of project-specific modifications, alignment between the approval scope and actual supply scope, and the maturity of the available evidence.
Related Reading:
- Chapter 4: Understanding Why IACS Introduced E26 and E27 — The Purpose Behind the Requirements
- Is a SoC-Centric Approach Enough for Ship Cybersecurity? — Statement of Compliance vs. Type Approval
- Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram
- Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects
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 →
Comments
Post a Comment