Regulatory requirements can be tedious, but at least the business imperative is clear: without documentation that meets the requirements, the organization will not be allowed to sell its products (or, in some cases, operate at all). Other business goals may exist but are secondary.
To begin, you need to understand the actual requirement. Some requirements are technical. For example, the U.S. Food and Drug Administration requires that content of labeling (drug information) be submitted electronically using the Structured Product Labeling (SPL) standard.1 SPL is an XML standard. Any content strategy that involves these regulated submissions must support the delivery of content encoded in SPL.
European Union legislation specifies that a technical product is only complete when accompanied by an operating manual. Delivery or sale of a product without an operating manual or with an inadequate manual breaks the law. In this case, users are entitled to assistance.
In the United States, only a few categories of product documentation are regulated, but concerns about legal liability may drive content decisions. One notable exception is the nuclear power plant licensing process. The U.S. Nuclear Regulatory Commission provides detailed requirements for the content of a licensing application.3
Another category of regulation is for component manufacturers, such as in the aerospace industry. If you make aircraft components, such as emergency exits or seats, your product documentation is subject to the requirements of your customer (such as Boeing or Airbus). If your customer informs you that you must deliver product documentation using S1000D (another XML standard) or a military standard, you have no choice but to comply. (Technically, these requirements are not “regulations,” but in your role as a supplier, the distinction is at best semantic.)
Regulatory requirements are best seen as prerequisites—they affect your content strategy decisions long before you can start thinking about how to create effective, useful content.