IEC TS 62666: Guidelines for Including Documentation Aspects in Product Standards

Product standards traditionally focus on technical specifications — dimensions, performance criteria, test methods, and safety requirements. Yet the documentation that accompanies a product — user manuals, installation guides, maintenance schedules, and compliance certificates — is equally critical for safe and effective product use. IEC TS 62666 addresses this gap by providing systematic guidelines for how product standards should specify documentation requirements. This Technical Specification, developed by IEC Technical Committee 3 (Information structures, documentation and graphical symbols), ensures that documentation is treated as an integral part of product delivery rather than an afterthought.

📋 1. Framework for Documentation Requirements in Product Standards

The standard establishes a structured approach for identifying and specifying documentation that should accompany a product or system. Key categories of documentation addressed include:

Documentation Category	Purpose	Example Content
Installation documentation	Enables correct physical installation	Site preparation, mounting, connections, commissioning procedures
User/operator documentation	Supports safe and effective operation	Operating procedures, control descriptions, safety instructions
Maintenance documentation	Defines servicing requirements	Inspection intervals, part replacement, lubrication schedules
Repair documentation	Facilitates corrective maintenance	Fault diagnosis, disassembly/assembly, testing after repair
Technical description	Provides design and functional understanding	System architecture, block diagrams, technical data sheets
Compliance documentation	Demonstrates regulatory conformity	Test reports, certificates of conformity, CE marking documentation
Decommissioning documentation	Addresses end-of-life handling	Disassembly instructions, waste disposal, environmental impact

💡 Engineering Insight: The most overlooked documentation category in product development is decommissioning documentation. Many product standards specify installation, operation, and maintenance documentation in detail but neglect end-of-life handling. With the growing emphasis on circular economy principles and extended producer responsibility (EPR), decommissioning documentation is becoming a regulatory requirement in multiple jurisdictions. When writing a product standard, always include a clause on decommissioning documentation if the product contains hazardous materials, batteries, or substances restricted under RoHS or REACH.

🔬 2. Documentation Structuring and Media Requirements

IEC TS 62666 provides detailed guidance on how documentation should be structured and delivered:

2.1 Document Set Concept

The standard introduces the concept of a “document set” — a structured collection of documents that together provide all necessary information for the product’s lifecycle. Key requirements include:

Non-revisable form: At minimum, documentation shall be delivered in a non-revisable form for legal record-keeping. PDF/A format (ISO 19005-1) is specifically recommended for long-term archiving.
Revisable form (optional): For products that may be modified after delivery, a revisable document set should also be provided to facilitate documentation updates.
Media selection: Documentation shall be supplied on media suitable for the expected use environment — paper for field use, electronic files for office use, or integrated into the product itself (embedded help systems).
Language requirements: Documentation language shall be specified in the product standard, typically including at least one widely used international language.

2.2 Structuring Principles

Each document within the set should follow consistent structuring principles:

Each document should have a unique identifier for traceability.
Revision history and change control information should be included.
Cross-references between documents in the set should be clearly indicated.
A document inventory or document list should be provided as part of the set.

⚠️ Critical Consideration: The standard specifically warns against the common practice of including documentation requirements in product standards simply as “the supplier shall provide documentation” without specifying what type, format, or content. This generic approach leads to incomplete documentation, user confusion, and potential safety liabilities. Every documentation requirement should specify: (1) the document type, (2) its intended audience, (3) minimum content requirements, (4) media format, and (5) when in the product lifecycle it must be delivered.

⚙️ 3. Engineering Application and Documentation Planning

For engineers writing product standards or specifying documentation deliverables, IEC TS 62666 provides a systematic planning checklist:

Planning Step	Question to Answer	Documentation Output
1. Identify lifecycle phases	What phases does the product go through?	Lifecycle phase list (install, operate, maintain, dispose)
2. Identify users	Who interacts with the product in each phase?	User role list (installer, operator, maintainer, recycler)
3. Identify information needs	What does each user need to know?	Information requirement matrix
4. Select document types	Which document types best meet each need?	Document set structure
5. Define content requirements	What specific topics must each document cover?	Document outlines / table of contents
6. Specify media and format	What medium and format for each document?	Media specification (paper, PDF, HTML, video)
7. Define delivery milestones	When is each document delivered?	Document delivery schedule

✅ Best Practice Recommendation: When developing a product standard that references IEC TS 62666, use the standard’s framework to create a documentation requirements table within the product standard’s normative clauses. For each documentation item, specify: document title, content description, intended audience, media format (with reference to ISO 19005-1 for archival PDF), language requirements, and delivery timing relative to product delivery. This approach transforms documentation from a commercial checkbox exercise into a structured engineering deliverable with measurable compliance criteria.

🔴 Common Pitfall in Product Standards: A frequent error is treating documentation requirements as informative (guidance only) rather than normative (mandatory). If safety-critical information must be communicated through documentation (e.g., maximum operating pressure, lockout/tagout procedures, emergency shutdown instructions), the documentation requirement must be stated in normative language using “shall” rather than “should” or “may”. Failure to do so can create ambiguity about whether the documentation is contractually required, which has implications for product liability and regulatory compliance.

❓ Frequently Asked Questions

Q1: Is IEC TS 62666 applicable to all types of product standards?

Yes, the guidelines are designed to be universally applicable across all electrotechnical product domains. The standard’s framework is domain-independent, focusing on the documentation process rather than content specific to any technology. Whether the product is a simple switch or a complex medical imaging system, the same documentation planning principles apply. The depth and complexity of documentation will vary, but the systematic approach to identifying documentation needs remains consistent.

Q2: What is the relationship between IEC TS 62666 and the documentation requirements in ISO 9001?

ISO 9001 (Quality management systems) requires organisations to maintain documented information as evidence of quality system operation. IEC TS 62666 complements this by providing domain-specific guidance on what documentation a product standard should require. In practice, a manufacturer’s ISO 9001 quality system defines the documentation process, while the product standard (informed by IEC TS 62666) defines the documentation content requirements for that specific product.

Q3: How should documentation be handled for software products versus hardware products?

For software products, documentation is typically more dynamic — online help systems, release notes, and API documentation that evolve with each version. The standard’s document set concept applies equally to software, but the media choices may differ: embedded help within the software UI, online knowledge bases, and machine-readable documentation formats. For safety-related software (per IEC 61508), documentation requirements are significantly more prescriptive, including requirements traceability matrices and verification reports.

Q4: Can documentation be delivered exclusively in electronic form?

Yes, but the standard recommends that at least one copy be provided in non-revisable form (e.g., PDF/A) for archival and legal purposes. Electronic-only delivery is acceptable where the operating environment supports it (e.g., equipment with integrated displays, software products with online help). However, for products used in environments where electronic access is impractical (field service, emergency repairs, remote installations), paper documentation should be specified as an additional deliverable.