If I Were an Authorizing Official (AO)

I have been involved in the Certification and Accreditation (C&A) and Assessment and Authorization (A&A) processes used by government customers since the DoD Information Technology Security Certification and Accreditation Process (DITSCAP) was released in 1997. As we progressed through the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) in 2006 and in 2014 moved to the DoDI 8510.01, "Risk Management Framework (RMF) for DOD Information Technology (IT)", I've gone through hundreds of security controls, thousands of assessment procedures, or Control Correlation Indenters (CCIs), authored and review dozens of policy and procedure documents, and otherwise managed accreditation packages that eventually navigated through an approval chain to obtain an Authority to Operate (ATO) issued by an Authorizing Official (AO). I've thought about what I would do if I was sitting in the AO's seat and here's what I'd look for:

• More time spent on risk assessment versus compliance. We are very good at applying checklists and providing compliance scores and dashboards, but not much time is spent analyzing assessment results, managing Plans of Actions and Milestones (POA&Ms), applying mitigations, and determining residual risk. At the end of the day, the AO needs to decide whether to authorize a system or not, and to do that, the risk of operating the system must be understood, not how many security controls are open.
• Develop, provide, and use the Continuous Monitoring Plan as soon as possible in the System/Software Development Lifecycle (SDLC). Per NIST SP 800-37, a Continuous Monitoring Plan should be submitted to the AO at Step 2 of the Risk Management Framework (RMF) process (Selection of Security Controls). Attention should be paid to the change management process, providing a security impact analysis for changes, and documenting the decision to accept the risk introduced with the change. The change management process needs to be clear as to what constitutes a major change that must be elevated to the AO for approval and what changes can be accepted by the team responsible for the day-to-day development, operations, and security of the system. An effective Continuous Monitoring Plan keeps the security posture of the system at the same level it was when it was authorized and there should never be a mad rush to clean it up before the ATO expires and the system will be reassessed.
• Don't be afraid of reporting bad news. Use your skills to find vulnerabilities. If open findings cannot be closed, expose them to the AO, and don't try to bury them in a POA&M that has unrealistic mitigations or milestones to close them. 
• Be more technical and less administrative. The assessment and authorization process should not be a paperwork drill to populate an Enterprise Mission Support System (eMASS) record. When looking at open findings in Security Technical Implementation Guide (STIG) assessments, discuss ways to close or mitigate the finding, and just don't open a POA&M item with an indefinite due date. Establish realistic milestones and follow up on due dates to make sure progress is being made.
• Use inherited controls from your common control providers. When deploying an application in Cloud Service Provider (CSP) environment, two NIST SP 800-53 control families should be entirely inheritable:  Physical and Environmental (PE) and Media Protection (MP) as well as several in Maintenance (MA). Many more security controls, particularly Incident Response (IR) should be inheritable from the Cybersecurity Service Provider (CSSP). Applying an enterprise policy record should further reduce the controls the system owner is responsible for. For example, on an Impact Level 4 system deployed in AWS GovCloud (US), we were able to inherit 91 CCIs from the CSP, 120 CCIs from the CSSP, and 435 CCIs from the enterprise policy record.
• Keep an accurate inventory. Know the operating systems, applications, databases, network components, and cloud resources (if applicable) within your accreditation boundary. Be aware of the cloud resources you are consuming are in scope at your Impact Level when deploying a DoD application in accordance with the DoD Cloud Computing Security Requirements Guide (SRG). Keep a STIG traceability matrix that is associated with your inventory. Be able to generate a Software Bill of Materials (SBOM) so if a major vulnerability such as Log4j is announced you'll know quickly whether you are affected and which systems need attention.
• Document data flows. Your architecture and data flow diagrams should reflect the external services your system needs to access, external connections to on-premise services, and interfaces to the CSSP for vulnerability assessment and log collection. Ports, protocols and services exceptions and firewall rules should align with data flow documentation.

Whether you are responsible for NIST SP 800-53, NIST SP 800-171, NIST SP 800-172, PCI DSS, ISO 27001, or another security control set, keep these points in mind as you perform your assessments. As a Defense Industrial Base (DIB) contractor, I sit in the position as the company official who has to implement, assess, and attest to compliance with the 110 NIST SP 800-171 security controls required per Cybersecurity Maturity Model Certification (CMMC) Level 2 - essentially an AO. I'm fortunate we have the in-house expertise and experience to be well along the way towards being ready to be assessed by a Cybersecurity 3rd Party Assessment Organization (3CPAO).