Where do product security requirements come from, and what makes collecting them hard?

From product safety regulations, industry-specific requirements, privacy and data protection laws, IoT security laws, cybersecurity laws, market-specific regulations, and security standards and guidelines. Collecting them is hard because laws conflict across markets, data must stay in certain countries, reporting deadlines are tight in many countries at once, and they come in different languages.

* Seven kinds of source feed one product's security requirements, and they differ per target market. *

Sources:

• Product safety regulations, such as medical device rules.
• Industry-specific requirements, for example rail, automotive or energy.
• Privacy and data protection laws (GDPR, PIPL).
• IoT security laws (UK PSTI, California SB-327).
• Cybersecurity laws (CRA, NIS2).
• Market-specific regulations.
• Security standards and guidelines (IEC 62443, ISO 21434, ETSI EN 303 645).

Challenges:

• Conflicting laws: one market demands access for authorities, another forbids it.
• Data residency: China's data laws, for example, require certain data to stay in China.
• Tight reporting deadlines in multiple countries: one exploited vulnerability can trigger parallel 24- or 72-hour reports to several authorities.
• Different languages.

Tax law is not a source of security requirements. Every source above is a reason the product has to behave securely.

Go deeper:

• Information security standards (Wikipedia) — the standards side of the picture