If you don't toot your own horn, there's no music! Here's a story of uncovering wonderful work already done by a software engineer who didn't know his documents were a necessary addition to the 510k.
An R&D team at a surgical instrument startup came to us in a bit of a panic. They were planning to submit their 510k in about a month, but they thought they didn't have any cybersecurity baked into their design. It was a small startup without a lot of extra funds, and the 510k was existentially important (if it didn't go through, their company would probably fail).
We assembled a team and hosted the first development workshop with the software engineers in the room. My team had reviewed the draft 510k documents and had a list of questions. As soon as we started asking our assessment/checklist questions, everyone in the room seemed to be relieved. It was clear that the software team had already done a tremendous amount of work to design key cybersecurity features (e.g., authentication, encryption). The gap was almost entirely in documentation. We closed the meeting after giving homework and sending a list of documents required, plus templates.
At the next workshop, we were blown away. The software dev team had already completed a month's worth of documents within a week. When we asked how they did it, one engineer raised his hand and said "I already had all of this. It's just what I do. I didn't know it was needed for the submission." He had data flow diagrams, threat analyses, and context diagrams. The biggest missing item was a table of contents to guide the reviewer through the document list.
Not only was the work already completed, but so was its documentation! (People who know software engineers should know what a feat that is - documentation is rarely their favorite activity, much less spontaneously developed.)
Many software architects build in security by design, but they don't provide the level of detail to the design history file or other records, because they aren't asked. I assume this previously common scenario has drastically changed in the last year, but the lesson still stands; ask people on the R&D team what they did, and find out there's probably a lot of goodness that could benefit your regulatory submission.
This goes beyond cyber. Many design choices at the individual engineering level are useful when writing a regulatory submission. Design choices tell a story of benefit-risk tradeoffs throughout the development cycle. Design choices over the course of premarket development are numerous. Not all need documentation, and fewer still go into a regulatory submission. I think we miss the opportunity, however, to provide a rich story and complete picture for FDA and others. The story provides the rationale for tradeoffs in benefit and risk, and can often serve as a swaying factor for a review team with a tough call to make.
~Shannon, the Optimistic Optimizer