As a Defense Business System (DBS) could you please provide guidance on what audit parameters we are subject to as per DoD? As an example, DoDi 5000.75 states the need for traceability from requirements to design.
Please advise on the best reference material to appropriately account for audit as we navigate our SDLC. Ideally we would pre-posture what we can, but also need reference materiel to validate any requirement and take the subjectivity out of it.
In order to provide context to your question please consider the following background information.
DoDI 5000.75 is the implementation instruction in DoD for Section 2222 Title 10, U.S.C. This statute is commonly referred to as the Clinger-Cohen Law, which covers IT investmentment requirements for the Federal Government.
Para. 1.2, Sub-para. b., states:" Business systems acquisition will facilitate business changes through doctrine, organization, training, materiel, leadership and education, personnel, facilities, and policy to drive performance improvements, efficiencies, effectiveness, cyber resilience, and audit compliance."
Therefore, audit compliance is statutorily required. Section 2222 Title 10, U.S.C. applies to all Federal Agencies, including the DoD. Guidance covering Federal Audit is in three documents known as the Generally Accepted Government Auditing Standards or "Yellow Book" [https://www.gao.gov/yellowbook], Standards for Internal Control in the Federal Government or "Green Book" [https://www.gao.gov/greenbook], and the Financial Audit Manual [https://www.gao.gov/financial_audit_manual]. The DoD reference for these guides is the DoD Audit Manual [https://www.esd.whs.mil/Portals/ 54/Documents/DD/issuances/dodm/760007m.pdf].
Because DBSs implement business workflows that are subject to audit there are two components to consider. The first are the IT or technical system controls required for audit compliance. These are found in the Federal Information System Controls Audit Manual (FISCAM) [https://www.gao.gov/fiscam] and the NIST Risk Management Framework (RMF) [https://csrc.nist.gov/Projects/risk-management/about-rmf]. If your program is a financial system, interfaces with a financial system, or the data is used calculating asset appreciation/depeciation, the cost of operations, such as HR it will likely need to comply with the Standard Financial Information Structure (SFIS) These cover the overarching system requirements that are applicable to all DBSs, but do not include business domain specific requirements that may be levied for HR or medical information, for example.
The other component is the business workflows themselves. Your agency has likely implemented business workflows that are for HR, finance, or logistics management, etc. that it believes meet auditability requirements. Your agency may have also published system policies for a business area that may drive a requirement for your system or program.
The audit team will evaluate not only the technical controls (FISCAM, RMF, and SFIS if applicable), but will also evaluate whether the DBS implemented the applicable policy correctly. If the business policy/workflow is not audit compliant it may require a policy change that could affect the DBS technical solution and maybe documented an audit finding or change request depending on your agency's internal process.
In summary your program office is likely deconflicting audit findings or observations that could be driven by technical controls, inconsistenecies in between the business policies and the DBS implementation, or shortcomings in the business policy. It was for this reason that DoDI 5000.75 shifted much of the responsibility to the Functional community. Notice in DoDI 5000.75 that the Acquisition community only leads the Acquisition phase (1 of of 5 phases) and that the Functional community leads the other four.