1. Start with the applicable requirement
The three parts of EN 18031 are not separate categories for networks, radio and IoT. Part 1 concerns network protection, Part 2 personal data and privacy, and Part 3 protection from fraud. Commission Implementing Decision (EU) 2025/138 cites the three standards with restrictions. First establish which RED essential requirements apply, then check the scope and limitations of the harmonised references. A list of standard numbers alone does not establish full presumption of conformity.
2. Describe the configuration placed on the market
An engineering sample may support only local control while the commercial version adds remote accounts, cloud alerts or payment features. Record connectivity, user roles, exposed interfaces, processed data, transaction functions and associated services. Mark each function as enabled by default, optional or maintenance-only. The record should describe the actual sales configuration and its dependencies.
3. Look beyond the enclosure
Document how the device, mobile app, management platform and external components interact. Which key validates an update? What can an app token access? Which local functions remain available when a cloud service fails? The assessment scope depends on the applicable requirements, risk analysis and testing authorization. External systems should not be actively tested without permission. Interface documentation, controlled environments and other acceptable evidence may be needed to explain dependencies.
4. Make evidence reproducible
Build a matrix linking each control to its design mechanism, test conditions, expected behaviour, result and evidence location. An assertion that communication is encrypted does not explain endpoint configuration, certificate validation or error handling. Similarly, an update feature needs an explanation of source verification, failure recovery and handling of older versions. These are preparation examples rather than universal implementation requirements. The applicable standard and product assessment determine what must be demonstrated.
5. Manage variants and remediation
Products sharing a platform may reuse some design evidence, but differences in radio modules, interfaces, sensors, storage, firmware or cloud features still need review. Record each remediation version, affected interface and regression scope. Reassess evidence when a feature changes during testing. This establishes which configuration a report covers and supports future decisions about additional verification.
6. Agree deliverables before testing
Confirm the report purpose, recipient requirements, samples, access rights, documentation language, remediation rounds and any involvement of a notified body. A test report records results within its agreed scope; it is not a universal approval for every market, version and regulation. Lead time and cost require a scoped assessment.
Contact LSD Lab
Shenzhen Ling Shi Da Testing Technology Co., Ltd. supports product cybersecurity testing, EN 18031 applicability assessment, gap analysis and remediation retesting. Telephone: 400-661-8031 / +86 185-9801-0056. Address: Zhimei Huizhi Technology Park, Fuyong, Baoan, Shenzhen, Guangdong, China. This article provides practical preparation guidance; confirm requirements against current official texts and the actual product configuration.