ISO 9001 does not require an external document master list so the auditor may be inventing a problem where none exists. Further, by suggesting a solution to the 4.2.3.f requirement the auditor is consulting and, if this is a Certification Body auditor, misbehaving.
A better audit question would have been, “What documents of external origin are used and how are they controlled?” This would be a valuable question to ask anyhow, for if there are no problems with the control and distribution of external documents, there is no need for a master list.
“Control and distribution” means making sure everyone is working to the correct versions of externally-generated documents, so the solution is more than a template: it's a process, of which a template might be a useful part.
Such documents will include, as has been said, specifications and drawings generated by customers and suppliers, contracts, reports generated by suppliers on request (e.g. reliability studies), international standards for equipment, components, interfaces and protocols, legal requirements, equipment manuals, calibration schedules, etc, etc. The intent is to make sure that everyone concerned can find the correct versions of such documents when they need to, that they are informed of changes, and perhaps are involved in approvals (e.g. of customer design change requests).
They do not necessarily need the latest versions of such documents and sometimes expressly need a specific, older version. For example, the help desk needs the documentation associated with product in the field, which might be a few revisions behind the material that R&D are working with. If there's a legal dispute, it may be necessary to go back to drawings, specifications, international standards and legal requirements pertaining at the time which, while obsolete, should be in the archives.
While most external documents will likely be available in some kind of internal (usually electronic) document control system, some (contracts perhaps) may only be in paper form and held confidentially by the contracts department, some (like international standards) will have been purchased, and some will be available on-line.
A single master list, if such is used, won't scale up. For organizations that have several projects or products in work at the same time, it will become a pinch point and the risk is that they will not use it. There might be a master list for each project in such circumstances.
But consider this: if the organization has a good electronic document control system, coupled with accountable document management processes (that, for example, identify those responsible for controlling documentation that comes from customers, from suppliers, from international standards bodies, from legal sources, etc, and faciliatating an appropriate change communication, review and approval process) and if documents are called up in a hierarchical structure by reference, one to another, what use is a master list?
A master list becomes rather cumbersome (or useless) when different teams need access to different versions of documents of external origin.
For example, we're communicating over the internet, and the communications protocol most of today's equipment uses is specified in something called IP, version 4. It's available online. The industry is working on equipment using a new version of IP, version 6, because IP v4 is running out of addresses and IP v6 offers the possibility of many, many more addresses. Specs for equipment like internet routers define whether they're IP v4 or IP v6 (or both). Many of the engineering companies that do this work employ knowledgeable engineers who do not need to be told what IP is or where to find its specs; it's part of their skillset. If their work involves contributing to developing and changing the IP v6 specifications themselves, they'll be communicating with other team members around the world using an internationally-agreed document control process, and trying to manage the IP specifications for such people using a master document list would be an unnecessary duplication of effort. (Furthermore, customers for such equipment usually only need to know if it's IP v4 or IP v6 (because they only want to know what they can connect to what) and do not need the specs themselves, so they won't attempt to control the specs as external documents.)
So I think the answer is not necessarily to give the auditor what is asked for, but instead find out what documents of external origin are used, how they are controlled now and whether the existing controls are effective. If they are, there's nothing to do. If not, maybe a master list would help, perhaps one per project or product line, but as part of a document control process. I would suggest that it might look like the suggestions above, and ought to show who is responsible for managing changes (not necessarily the same person) and making sure everyone who needs to know of changes is informed in a timely fashion. It also needs to take account of archiving previous versions in order to support maintenance of previous versions, and any liability issues that might arise.
Hope this helps,
Pat
