When referencing a standard written or published by another organization, the first issue to keep in mind is that of copyright. Quoting a standard owned by another organization may make them angry. Some standards organizations are essentially publishing houses, this is especially true of ISO. They make their money by selling standards that have been written by volunteers from other organizations. Including somebody else’ copywritten text in your standard can lead to a world of hurt.
Public access to standards has become a very big deal in the US and has led to years of court battles due to the practice of governments adopting voluntary standards as regulation. This means that the standard becomes a regulation that must be followed. The problem is that to access the now governmental requirement you may have to pay private companies for a legal copy of the standard.
This leads us into the difference between 'voluntary standards' vs. 'mandatory standards'. If you need to go too far down this rabbit hole, just start a Google search. Mandatory standards are common in some fields, especially related to food safety.
Back to referencing another standard in your standard.
Here are a few suggestions on how to do it and what the pitfalls may be and how to avoid them:
In brief, my best advice is: never quote another standard in your standard. Just reference the standard, part of the standard or just one requirement that you want to include in your requirements.
The 'normative references' section of your standard should list the documents that you reference, either in whole or in part, in your standard as normative. (For more on what we mean by normative see my post on ‘normative vs. informative’.)
You can always write your own requirement, even if it covers the same area as in another standard - just don't copy their text.
It is usually best to reference standards that your target industry or sector already uses rather than create a new requirement. If your standard references these other standards (or standard-like documents such as codes of practice or lists of principles), the user is likely to be familiar with the requirement and may already be implementing it.
Referencing existing standards that are in use in your industry has two other benefits:
If you write your own requirements for practices that are already covered by other standards, you may find that this becomes a disincentive for folks to use your standard. They may see your new requirement as creating confusion or overlap with their existing policies or practices. They may be required to implement two sets of requirements for the same thing (e.g. two different sets of requirements on record keeping).
If you write your own requirements, then it is on you to make sure the requirements are kept current with evolving regulations and norms. If you reference a standard from a credible organization, it is their responsibility to update their own standard as needed. This may be a small matter for some issues but in areas you may not want to spend your resources developing the capacity to be on top of a complex technical issue when someone else has a helpful solution (e.g. a living wage calculator).