The process starts by capturing requirements (for example in a mustard yaml file). These requirements are written in such a way that the individual rules of a standard are encapsulated where possible, and they must be both machine testable and human readable. They are contained in the project repo.
A patch review system is put in place, which ensures that each revision is traceable to the developer (this will require careful implementation). If the code within the patch satisfies a previously unaddressed requirement or introduces a new feature, this must be expressly stated in the commit message. The enforcement of this aspect can be partially automated (patches that do not have an explanation message, or the correct credentials, can be rejected, for example), however the commit messages are primarily for ease of human auditing, and will be retained as metadata for consumption downstream in the process when documentation is generated.
The patch tracker is integrated with a CI system, which ensures that a submitted patch does not break any features. This means that code which implements a particular requirement of the system can be shown to function as expected, as well as being directly linked to specific SLOC and the developer who merged it. Often, a standard will dictate its own rules regarding patch review, which can be integrated at this point.
The CI runs tests on the code, and test results are produced as a standalone artifact. An automerger is configured with both human and machine reviewing, which creates a branch consumed by a continuous deployment system.
The CD system runs a script which consumes the requirements yaml, as well as the test result artifacts and information from the patch tracker to generate an output with a compliance narrative for each individual requirement/standard control (including the patch commit messages), their accompanying test results, and information about who submitted the patch(es). This is updated every time there is a revision to the code, requirements or standard. This output can be consumed by an automatic compliance document generator (such as Compliance Masonry) to produce consistently up-to-date compliance documentation as the project develops.