"Backup" or "ISO 9001" Ratsnest, what files?

We're trying to straigten out our ISO9001:2008 process, and it's a ratsnest.  A more simple description of our need would be to say that we simply want to make sure that we have a "minimal yet sufficient" set of files backed up.  So, you could view this question as being simply about WHAT to backup, minimally.

This gets SOOOOO complicated, that I would greatly appreciate your responses to be numbered in sync with my numbers below, so that I can keep track of what goes with what.  And what I'm looking for is recommendations, shortcuts, anecdotes, your standard, of whatever!

Here is my take on things so far:

1. I'm tending toward a whole backup of the complete development folder structure.  This will guarantee "sufficient", but it's far from "minimal".  Of course, the potential future cost of having attempted minimal and finding you're acutally INsufficient, could be large.
   
2. The schematic (.dsn file) is definitely NOT freestanding.  Our current process backs up only that file.  However, I find that BOM generation uses the column output specification from the project (.opj file).  Already, we have some customized columns for the BOM.  At this time, one could argue that these customizations are easily understood and could be re-created by hand after restoring only a .dsn file.  But I fear that in the future there may be less obvious customizations, subtle customizations that might get forgotten when one ought to be re-created them, and might lead to serious costly problems not discovered until AFTER production.  And there are likely OTHER things in the opj file that are similarly unique and important.  Therefore, I think it's necessary to back up BOTH the .dsn and .opj files.  Of course, how we do that with our current system is not trivial.  Our current system and process revolves around single files.
   
3. The board (.brd file) is also NOT freestanding.  One of two examples I have encountered involves the art_param.txt file.  It seems that the .brd file might specify a pretty industry standard GERBER_RS274X format.  If I put that .brd file alone in a folder and then try to generate artwork, PCB Editor creates a default art_param.txt file that specifies instead the Gerber 6x00 format.  Fortunately, I get a warning and can take care of this.  But what OTHER things might be more subtle?  Another problem is the format integer and decimal places.  I'm not sure where the one side comes from, the .pcb or library symbols, but that also always mismatches the art_param.txt file defalt content.  For that, it's less easy to correct.  I have to go look at an older correct board (I normally go into Manufacturer / Artwork / General Parameters but now know I could look in an old art_param.txt file) and write down the two numbers, then go to my new board and type them in.  While I also get an error message here, I'm concerned that I might some day put in an answer that causes problems further down the road.  Furthermore, I am MOST concerned about some OTHER change that I or another designer may make, that turns out to be CRITICAL but for which no error message is produced.  This concern makes me adamant about including the art_param.txt file with the .brd file.  There's also a naming convention problem related to this.  Our system enforces a naming convention.  Over on the .sch and .opj files, they had the same root filename, so the naming convention is not an issue.  For a .brd file and the art_param.txt file, the art_param.txt file has a DIFFERENT root filename from the .brd file, and also a duplicate file name across multiple boards.  This is problematic.
   
4. It gets worse for the .brd file.  Drill sizes appear to be originated in the .brd file and so the NC Drill file outputs are true outputs that can omitted from backup and reproduced from the .brd file.  This is NOT TRUE of router bits, however.  It appears that the ncroutebits.txt file originates the router bit sizes, which are NOT stored in the .brd file.  It's also possible to specificy center or edge routing, which it seems is stored in the .brd file.  What a bag of worms!  If one specifies center routing in the .brd file, then the final location of the routed edge will depend on not only the .brd file info, but also the ncroutebits.txt definition of the router bit size.  Of course, this means the ncroutebits.txt AND the art_param.txt need to be backed up with the .brd file.  And then there's another naming convention complication with the ncroutebits.txt file not having the same root filename as the .brd file.
   
5. And then the bag of worms really hits the fan when it comes to the symbol libraries.  I have at least two libraries that each project uses, and within the folder are both schematic symbols and pcb footprints.  We currently backup schematic and pcb separately, but this single folder contains necessary stuff for both, all in one place.  Again, this hints toward a single bulk save of a zip containing everything.  But right now, I have multiple projects using the same symbol folder.  And I do run the risk that if I ever update a footprint, for example, I may make it incompatible with an older pcb.  These leads me to want to really waste disk space by making a COPY of the symbol folder for EVERY PROJECT.  I can still start off new projects by copying an older symbol folder, and in the future I can even merge contents from two into one, for a new project that wants to take advantage of development work done on two different footprints (or schematic symbols) previously developed for the first time for two other older projects.  But still, I would need a lot of disk space (albeit cheap nowadayws) for a full copy of the symbol folder for every project.
   
6. Over on our software side, we already went to the point of simply a wholesale zip of the complete workspace.  Software development IDEs are equally "spread out", so you need to include all the files to be sure you have everything.  Which compile optimization options are used come from the project normally.  What source files contain come from a bunch of .c files.  And there are a bunch of .h files.  Precompiled headers might not be needed, but that get swooped up in the process, obviating the fact that such wholesale zipping is "sufficient" but NOT "minimal".
   
7. In addition there's version correlation.  For decades, yes decades, I always keep my schematic version numbers matching my PCB version numbers, even if a PCB-only change occurs.  I just duplicate my schematic, unchanged, but with a new version number matching the PCB.  Our system currently does NOT enforce this.  So we could update a PCB version number and not the schematic version number.  This then implies that we need another layer of doc to correlate what schematic goes with what PCB.  I don't like this one bit.  So I still want to march those numbers in lock step with one another.  If we go to wholesale zipping, then this lock step is better enforced.
   
8. Ha!  Then what about the software?  These are embedded systems.  This version of software only works on such and such or later version of hardware.  This suggests updating software version numbers in lock step with schematic and pcb as well.  But software changes so rapidly compared to hardware, that I do NOT like this idea.  For this, I guess, we DO need that extra doc layer to say what version of software goes with what version of hardware.  So this all leaves me leaning toward TWO wholesale zips.  One for schematic and pcb and symbol folders.  Another for the software development IDE folder(s).