Operating the Governed Cloud: Security, Configuration, and Service Continuity
Configuration, monitoring, vulnerability, change, and recovery decisions after handoff
BLUF: A cloud service can keep running while the record that explains it drifts away from what is deployed. When configuration, control evidence, changes, and recovery steps sit in separate tools with separate owners, an organization loses track of what is running, who approved it, and whether it can be restored. Leaders should judge operational governance by whether a reviewer outside the operating team can reconstruct that record without the original builders. This paper proposes a testable operating baseline, consequence-scaled change paths, vulnerability response as a recorded risk decision, and a decision-rights model and closes with a 60-day pilot that tests the approach on one service.
Audience: System and service owners, operations and security leads, and the authorizing officials responsible for cloud services after authorization in defense and commercial organizations.
Scope: This paper begins at operational handoff, where its companion, Designing the Governed Cloud: Architecture, Integration, and Accountability (Preyna, 2026), ends. It covers configuration baselines, continuous monitoring, vulnerability response, change, incidents, and recovery operations. Migration planning and target-state design are addressed in the companion paper.
Why the approved record drifts in production
Cloud operations rarely fail because one document is missing. More often, configuration, change, security, monitoring, and recovery evidence is spread across separate systems, teams, and providers. Each record may be accurate for its own purpose, yet none reconstructs the decision that governs the service as it runs today.
Designing the Governed Cloud examined the decisions that precede migration and authorization: placement, integration, accountability, risk, and acceptance evidence (Preyna, 2026). This paper starts at handoff. An approved architecture is a starting record, and later changes, incidents, and recovery exercises test whether its assumptions still hold. Some of them will send the organization back to its design decisions.
The objective is an operational baseline that connects the approved service to its current configuration, control evidence, significant changes, and accountable owners. That evidence will usually live in several tools. An independent reviewer should still be able to reconstruct what changed, who approved it, and why.
This paper draws on two ACC3 International subject-matter experts: Stephen Fernandez, Chief Technology Officer (CTO), and Patrick Grau, Senior Technical Advisor. Each completed a role-specific written questionnaire prepared for this paper (S. Fernandez, personal communication, November 2, 2026; P. Grau, personal communication, November 2, 2026). Unless another source is cited, statements attributed to either of them come from these communications. Their input supplements the research cited here as practitioner evidence; it reflects professional judgment and experience, not independent empirical validation.
Fernandez focuses on the gap between policy and operational practice, especially when expedited changes outpace approval and documentation. Grau adds the technical caution that cloud environments and their documentation age continuously as services, software, provider requirements, and dependencies change.
1. The operational record can fail while the service continues to run
Consider a hypothetical cloud application that stays available after a routine network change. Weeks later, an assessor asks whether a restricted management interface remains isolated. The deployment pipeline shows that a change occurred, the ticket shows that someone requested it, and the security repository contains an earlier diagram. What none of them shows is whether the production configuration still matches the approved design or whether the change received the right review.
Figure 1 shows the pattern. Tickets, deployment records, control evidence, and monitoring data all exist, yet no single record explains what changed, who approved it, and whether production still matches the approved state.
Figure 1
Change, deployment, control, and monitoring records can each be complete while none of them reconstructs the current operating decision.
Note. ACC3 original figure. Record types are illustrative and vary by organization.
Fernandez describes a mainframe team that repeatedly recycled a CICS region during a critical outage. The repeated recycling suggested that no one had investigated the underlying cause. The platform is old, but the lesson is current: recurring incidents should trigger root-cause analysis and a lasting correction rather than another isolated repair.
National Institute of Standards and Technology (NIST) Special Publication (SP) 800-137 describes information security continuous monitoring as maintaining visibility into assets, threats, vulnerabilities, and control effectiveness so that organizations can respond to changing risk (Dempsey et al., 2011). That visibility pays off only when someone interprets the evidence and decides what follows. Without that step, a busy dashboard tells operators very little.
2. Preserve a baseline that operations can test
An operational baseline identifies the approved components, configuration expectations, dependencies, interfaces, owners, and evidence sources for a service. It is a reference point for comparing desired and observed state, so it cannot be a static diagram stored after go-live.
Figure 2 treats the baseline as an operating loop. Variance is detected, explained, and tested, and then it is either incorporated into the approved record or remediated.
Figure 2
The baseline stays valid only while variance is detected, explained, and either approved into the record or removed.
Note. ACC3 original figure. The rebuild step tests whether operations can reproduce the documented configuration. It does not by itself establish that the configuration is secure.
Grau recommends regular checks against both the documented model and the live environment. He treats unexplained drift, missing or outdated documentation, and assumptions about cloud services or software components as early warning signs, because environments and documentation change constantly in the cloud.
Automation does not guarantee an accurate baseline. Rahman and Williams (2019) examined 2,439 open-source Puppet infrastructure-as-code scripts from 94 repositories and found that source-code properties, including hard-coded strings, were associated with defective scripts. The study reports correlations in open-source repositories rather than a general cloud failure rate. Its practical lesson is to test deployment artifacts as carefully as the systems they create.
NIST SP 800-128 places security-focused configuration management within an organization’s overall configuration management (Johnson et al., 2011). A difference between the baseline and production can be legitimate. The record should still show whether the difference was authorized, what it affects, how it was tested, and whether the baseline or the service changed in response.
The companion paper proposed a handoff test: can operations staff reproduce the environment without the original developers (Preyna, 2026)? That test belongs in sustainment reviews too. Recovery instructions, access procedures, inventories, and deployment descriptions should be exercised as software versions and personnel change, because a package that worked at go-live can fail six months later.
Grau prefers a direct check: rebuild the approved configuration exactly as documented and investigate where it fails. In a poorly documented environment, he would first inspect the running system, establish a functional baseline, and test a sandbox clone. A rebuild does not establish that an environment is secure. It does expose missing dependencies and outdated instructions quickly.
3. Treat security controls as observable operational commitments
A control statement defines a requirement, and operations has to determine whether the mechanism behind it still works. Access control, for example, depends on group membership, application enforcement, periodic review, and a provider identity service. An assessment of the original implementation cannot show that all of those dependencies remain sound indefinitely.
NIST SP 800-53 Rev. 5 organizes controls into families that include Configuration Management; Assessment, Authorization, and Monitoring; Incident Response; Contingency Planning; Audit and Accountability; and System and Information Integrity (Joint Task Force, 2020). In production, these families interact. A failed logging pipeline weakens incident investigation. An overdue patch calls for an interim risk decision, and a changed recovery location can affect access or data-protection controls.
Continuous monitoring should connect each material finding to an affected asset, an owner, a disposition, and the evidence used to close or accept it. Under the Risk Management Framework, a plan of action and milestones (POA&M) records the planned remediation for a deficiency, and the authorizing official approves it (Joint Task Force, 2018). An open POA&M item documents the risk. It does not resolve it.
Grau advises keeping logs, alerts, and metrics simple and actionable, and he recommends that organizations not collect more information than they will manage. Monitoring tools should help service owners understand failures and deviations. Volume alone is not visibility.
ISO/IEC 27001:2022 specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system (International Organization for Standardization & International Electrotechnical Commission, 2022). The Cloud Security Alliance’s Cloud Controls Matrix (CCM) offers a cloud control framework, and its shared security responsibility guidance clarifies responsibility among actors in the cloud supply chain (Cloud Security Alliance, 2026). Neither framework supplies production evidence. Organizations still have to define how findings, changes, and tests enter their operational record.
Risk owners need a current account of exposure, and several roles hold part of it. Under the Risk Management Framework, the authorizing official is the only organizational official who can accept security and privacy risk, and that official also decides whether a significant change requires reauthorization (Joint Task Force, 2018). DoD programs add an information system security manager (ISSM) and an information system security officer (ISSO) at the system level (Department of Defense, 2022). Security leads, system owners, operations managers, and independent assessors hold the rest. The record should make each role’s authority and evidence explicit.
Fernandez emphasizes that security professionals should not grade their own work. Independent assessment, appropriate penetration testing, and timely corrective action are part of operating security, and risk acceptance requires an accountable leader with the knowledge and authority to make that decision.
4. Treat vulnerability response as a recorded risk decision
Vulnerability response tests the operating record more often than any other activity. NIST describes four responses to software vulnerability risk: accept, mitigate, transfer, or avoid (Souppaya & Scarfone, 2022). Patching is the usual mitigation, but the same guidance recognizes that it is sometimes not viable. A patch may not exist yet, the software may be past end of life, or deployment may have to wait for testing or a maintenance window. Each of those cases leaves a risk decision that someone has to own.
The guidance also describes a life cycle that fits the operating baseline: know which assets and software are affected, plan the risk response, execute it, and verify that it worked (Souppaya & Scarfone, 2022). The first step depends on the inventory described in Section 2. The last step needs evidence that the fix reached every affected asset; ticket closure alone does not show that. In SP 800-53, the controls most directly involved are RA-5, Vulnerability Monitoring and Scanning, and SI-2, Flaw Remediation (Joint Task Force, 2020).
Federal cloud programs are changing how they keep this record. FedRAMP’s Rev5 continuous monitoring playbook called for monthly scanning of operating systems, web applications, and databases. It tracked each unique vulnerability as its own POA&M item and sent deviation requests, such as risk adjustments, false positives, and operational requirements, to the agency authorizing official (Federal Risk and Authorization Management Program [FedRAMP], 2025). Since June 24, 2026, FedRAMP has kept that playbook only as legacy reference material for the transition to its Consolidated Rules for 2026 (FedRAMP, 2025). The new rules eliminate POA&Ms for cloud providers and replace them with a list of accepted weaknesses (FedRAMP, 2026e).
The Vulnerability Detection and Response rules require providers to detect and respond to vulnerability persistently through automated systems, and they state that this work is not limited to traditional vulnerability scanning (FedRAMP, 2026c). The Vulnerability Evaluation and Reporting rules require providers to report that activity at least monthly and to classify any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability, with an explanation of why (FedRAMP, 2026d). For Rev5 providers, both rulesets have been open to optional adoption since July 4, 2026. They become required to obtain or maintain certification on December 7, 2026, and their grace period ends March 7, 2027 (FedRAMP, 2026c, 2026d).
Under the Collaborative Continuous Monitoring rules, providers supply an Ongoing Certification Report every three months, and each agency makes its own risk-based decision about ongoing authorization. These rules become required for initial Rev5 certification on January 1, 2027, and for maintaining certification on April 2, 2027, with a grace period ending October 1, 2027 (FedRAMP, 2026a). DoD policy holds program managers accountable for coordinating decisions to withhold or delay vulnerability remediation during sustainment with the authorizing official and other stakeholders (Department of Defense, 2022).
Commercial organizations work under different rules, but the question is the same. Who decided to leave this exposure in place, on what evidence, and until when? A vulnerability record that answers those three points is a governed decision. One that does not is an unmanaged backlog.
5. Make change decisions visible across organizational boundaries
Changes should be classified before deployment, because review depth should follow consequences. Figure 3 shows three operating paths. Routine and material changes call for increasing evidence and authority, while an urgent change takes an expedited path defined by time pressure. Every path returns an observed result to the current baseline.
Figure 3
Routine and material changes call for increasing evidence and authority; urgent changes take an expedited path that still ends in a mandatory follow-up review.
Note. ACC3 original figure. The arrow reflects review depth for routine and material changes. Urgency describes time pressure rather than consequence, so an urgent change can carry any level of consequence and still returns to the same follow-up review.
Grau recommends regular review and audit, with documentation updated as soon as possible after changes are made. Fernandez identifies changes made outside the approved process as a practical warning sign, particularly when teams do not follow mandated security procedures or bypass documentation in the name of expedience.
ISO/IEC 20000-1:2018 sets requirements for service planning, transition, delivery, monitoring, and continual improvement (International Organization for Standardization & International Electrotechnical Commission, 2018). FedRAMP’s Consolidated Rules for 2026 offer a federal example of change governance. The Significant Change Notification rules require providers to evaluate changes, keep auditable records of those evaluations, and document emergency changes after the fact (FedRAMP, 2026b). These rules are new. Rev5 providers may adopt them now, and they become required for initial and ongoing certification on January 1, 2027, with a grace period ending June 1, 2027 (FedRAMP, 2026b). The process that applies to a given service still follows its governing obligations.
6. Treat service continuity as an evidence problem
Availability monitoring can show that infrastructure is running while users still cannot complete a critical transaction. A restored server is useful, but recovery is complete only when the service can perform its intended function under the expected conditions.
NIST SP 800-34 Rev. 1 ties contingency planning to organizational priorities, system dependencies, and life-cycle management (Swanson et al., 2010). A recovery time objective states a target, and only an exercise shows whether the service can meet it. Figure 4 frames recovery as an end-to-end test in which infrastructure, identity, dependencies, data, application function, critical transactions, and acceptance all have to return.
Figure 4
Recovery evidence should cover the whole chain from infrastructure startup to service acceptance.
Note. ACC3 original figure. The left-to-right order is illustrative. Actual restore order depends on the service’s dependencies, and some steps can run in parallel.
Fernandez argues that recovery plans should be exercised with the people and resources expected to perform the work. Investment should reflect service criticality and the consequences of disruption, subject to mandated requirements, and the gaps an exercise reveals need owners and corrective plans. Grau’s account adds a sequence worth copying: deploy, recover, run automated application tests, and verify the intended service function. In one effort he described, ACC3 used scripts to move across three environments within one week. Other services will have different dependencies and recovery times, so the transferable lesson is the sequence.
Published incident studies point the same way. Gunawi et al. (2016) examined public reports and postmortems on outages across 32 popular internet services. Ghosh et al. (2022) studied high-severity incidents in Microsoft Teams and reported difficulties in detection, root-cause analysis, and mitigation, and Chen et al. (2020) identified incomplete dependencies and imprecise health assessment as obstacles to diagnosing unexpected incidents. These are retrospective records from large providers, and they cannot establish how often failures occur elsewhere. They do pose a fair question for any operating team: can it trace an interruption through the dependencies the service relies on?
Table 1 connects those findings and the infrastructure-as-code study in Section 2 to specific operating decisions.
Table 1
Published incident and infrastructure-as-code studies each point to an operating decision.
| Study |
Observed evidence |
Operational implication |
| Rahman & Williams (2019) |
Defective open-source Puppet scripts associated with identifiable source-code properties |
Review and test deployment definitions; do not equate automation with a valid baseline |
| Gunawi et al. (2016) |
Documented outages across diverse online services |
Test recovery paths and account for service dependencies |
| Ghosh et al. (2022) |
High-severity incidents showed delays across diagnosis and mitigation |
Retain evidence from before and after events; rehearse response |
| Chen et al. (2020) |
Incomplete dependencies and imprecise health assessment impeded incident management |
Preserve dependency records and corroborate monitoring signals |
NIST SP 800-61 Rev. 3 places incident response within cybersecurity risk management and addresses preparation, detection, response, and recovery (Nelson et al., 2025). For a cloud service, preparation includes deciding which provider, platform, identity, application, and network records must be retained before an event occurs. Grau would keep the logs needed for troubleshooting, including dependency, network, error, and security logs, and he would correlate them with known changes and patterns across components.
7. Keep responsibility attached to decisions and evidence
Technical visibility does not settle questions of authority. In a cloud system, the provider and the consumer share control of resources, and the split depends on the service model (Liu et al., 2011). A provider may operate infrastructure and managed controls while the customer keeps obligations defined by the service arrangement. Inside the organization, the record should name who implements a control, who verifies it, who accepts residual risk, and who funds remediation.
Fernandez places accountability with the authorities and owners defined by policy and system documentation, a principle that applies whether the organization is a defense program or a commercial enterprise. He also cautions that oversight must not become a self-reviewing loop in which the people performing the work are the only people evaluating it.
Table 2 offers an illustrative model for reconciling operational roles with contracts, cloud service arrangements, and authorization requirements.
Table 2
Each operating decision needs a producer of evidence and a separate accountable owner.
| Decision or evidence |
Operational producer |
Accountable decision owner |
| Configuration deviation and correction |
Platform or application engineering |
Designated configuration/change authority |
| Security finding and remediation evidence |
Security operations and technical owner |
Risk owner; authorizing official when required |
| Service performance and exceptions |
Service management and monitoring teams |
Named service owner |
| Recovery execution and exercise record |
Operations and recovery teams |
Service or mission owner |
| Material change to authorization assumptions |
Engineering and security personnel |
Applicable designated authorization authority |
Escalation routes matter when ownership is disputed or remediation threatens mission availability. The process should identify who can decide, what evidence that decision requires, and when executive leadership becomes involved. An unresolved owner belongs in the record as a governance finding and should be routed like any other.
8. Measure the questions leadership must answer
Operational measures should help leaders decide where to act. The number of controls documented, tickets closed, or dashboards created says little about whether a service is understood, protected, recoverable, and meeting its purpose. Better measures connect a management question with evidence and a defined response.
ISO/IEC 20000-1:2018 supports this approach by treating service management as planned, measured, and continually improved (International Organization for Standardization & International Electrotechnical Commission, 2018). Metrics should be interpreted with care. Ticket closure can hide vulnerabilities that keep reopening, while a favorable availability percentage may conceal failures in critical user transactions.
Grau recommends focusing on the basics: minimum uptime and functionality, with alerts that address recurring problems or patterns of failure. Fernandez prefers concise reporting that highlights risks and incidents requiring a leadership decision, rather than detailed technical information leaders cannot act on.
Table 3 pairs five leadership questions with candidate evidence and the response an exception should trigger.
Table 3
A measure earns its place when it answers a leadership question and triggers a defined response.
| Operational question |
Candidate evidence |
Management response |
| Is the deployed state understood? |
Drift age; unowned assets; baseline exceptions |
Assign ownership and disposition material variance |
| Are controls still effective? |
Overdue findings; assessment coverage; verified fixes |
Prioritize remediation or record risk decision |
| Can the service be restored? |
End-to-end recovery exercise results; missed objectives |
Correct dependencies and retest |
| Are decisions reconstructable? |
Changes linked to approvals, tests, and revised records |
Repair missing evidence at the source |
| Is the service meeting its purpose? |
User transaction availability; latency; recurring incidents |
Adjust capacity, design, support, or service expectations |
These indicators are examples. A service owner should choose a small set aligned with mission and risk tolerance, define how often each is collected, and decide in advance what action follows an exception. NIST SP 800-137 frames monitoring information as support for timely risk decisions (Dempsey et al., 2011).
9. Carry operational obligations through the delivery lifecycle
The operating baseline begins before production. Requirements, acceptance criteria, architecture assumptions, deployment definitions, and recovery expectations determine what operations will later have to verify.
ACC3 designs Alchemist AI Pro™ to establish a structured requirements baseline for development. Within the Alchemy SDLC™ approach, that baseline is carried through governed delivery before an application enters operations and through later versioned development. Grau is explicit about the boundary: ACC3 does not currently use these products to carry all sustainment records, and Alchemist AI Pro™ does not administer or secure production systems. Organizations still need their own operating rules, monitoring, responsibility assignments, and evidence-management practices. Feeding validated operational findings back into versioned requirements is a possible integration that ACC3 has not yet built or tested.
ACC3 also designs Odysseus for AI-assisted Security Technical Implementation Guide (STIG) compliance and Authority to Operate (ATO) orchestration. ACC3 describes Odysseus as using an organization’s historical compliance data to pre-populate responses for its team to review and as routing STIG tasks to subject-matter experts (ACC3 International, n.d.). This paper does not evaluate it, and none of the practices described here depend on it.
A 60-day pilot
Do not choose the easiest service. Select one consequential production service with at least one material change in its recent history and at least one dependency that crosses an ownership boundary, such as identity federation or a provider-managed control. Within 60 days, the pilot team names provisional decision owners using Table 2, assembles the operating record described in Sections 2 through 5, and schedules an end-to-end recovery exercise against Figure 4.
The success test follows from this paper’s central claim. Using only the record, a reviewer outside the operating team reconstructs the service’s current configuration, its control evidence, its open vulnerability decisions, and one material change: what changed, who approved it, and why. A team that did not build the service then restores it through the chain in Figure 4 to an accepted critical transaction, again using only the record. This carries the companion paper’s handoff test from go-live into sustainment (Preyna, 2026).
Record where either test fails, which decisions lacked an owner, and which evidence existed only in someone’s memory. Where findings accumulate, Grau would address them through a structured hardening sprint with clear artifacts and an accountable outcome. A pass gives leadership a tested pattern for the next service. A failure shows, at the cost of one service, where the operating record is incomplete, and those findings return to design decisions, acceptance criteria, or operating responsibility (Preyna, 2026).
Getting Started with ACC3 International
ACC3 International recommends a focused working session with your service owner and your operations, security, and authorization leads or designated staff representatives. The session selects the pilot service, names the provisional decision owners, and agrees on the evidence the outside reviewer will use.
References
ACC3 International. (n.d.). Odysseus: AI-assisted STIG compliance & ATO orchestration. Retrieved November 4, 2026, from https://acc3int.com/odysseus/
Chen, Z., Kang, Y., Li, L., Zhang, X., Zhang, H., Xu, H., Zhou, Y., Yang, L., Sun, J., Xu, Z., Dang, Y., Gao, F., Zhao, P., Qiao, B., Lin, Q., Zhang, D., & Lyu, M. R. (2020). Towards intelligent incident management: Why we need it and how we make it. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (pp. 1487–1497). https://doi.org/10.1145/3368089.3417055
Cloud Security Alliance. (2026). Cloud Controls Matrix and CAIQ v4.1. https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1
Dempsey, K. L., Chawla, N. S., Johnson, A., Johnston, R., Jones, A. C., Orebaugh, A. D., Scholl, M. A., & Stine, K. M. (2011). Information security continuous monitoring (ISCM) for federal information systems and organizations (NIST Special Publication 800-137). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-137
Department of Defense. (2022, July 19). Risk management framework for DoD systems (DoD Instruction 8510.01). https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001p.pdf
Federal Risk and Authorization Management Program. (2025, November 17). FedRAMP continuous monitoring playbook (Version 1.0) [Legacy documentation]. https://www.fedramp.gov/legacy/playbook/csp/continuous-monitoring/intro/
Federal Risk and Authorization Management Program. (2026a). Collaborative continuous monitoring. FedRAMP Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/rev5/rules/collaborative-continuous-monitoring/
Federal Risk and Authorization Management Program. (2026b). Significant change notification. FedRAMP Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/rev5/rules/significant-change-notification/
Federal Risk and Authorization Management Program. (2026c). Vulnerability detection and response. FedRAMP Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-detection-and-response/
Federal Risk and Authorization Management Program. (2026d). Vulnerability evaluation and reporting. FedRAMP Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-evaluation-and-reporting/
Federal Risk and Authorization Management Program. (2026e). What’s changing. FedRAMP Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/updating/changes/
Ghosh, S., Shetty, M., Bansal, C., & Nath, S. (2022). How to fight production incidents? An empirical study on a large-scale cloud service. In Proceedings of the 13th Symposium on Cloud Computing (pp. 126–141). https://doi.org/10.1145/3542929.3563482
Gunawi, H. S., Hao, M., Suminto, R. O., Laksono, A., Satria, A. D., Adityatama, J., & Eliazar, K. J. (2016). Why does the cloud stop computing? Lessons from hundreds of service outages. In Proceedings of the Seventh ACM Symposium on Cloud Computing (pp. 1–16). https://doi.org/10.1145/2987550.2987583
International Organization for Standardization & International Electrotechnical Commission. (2018). Information technology - Service management - Part 1: Service management system requirements (ISO/IEC Standard No. 20000-1:2018). https://www.iso.org/standard/70636.html
International Organization for Standardization & International Electrotechnical Commission. (2022). Information security, cybersecurity and privacy protection - Information security management systems - Requirements (ISO/IEC Standard No. 27001:2022). https://www.iso.org/standard/27001
Johnson, A., Dempsey, K., Ross, R., Gupta, S., & Bailey, D. (2011). Guide for security-focused configuration management of information systems (NIST Special Publication 800-128, includes updates as of October 10, 2019). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-128
Joint Task Force. (2018). Risk management framework for information systems and organizations: A system life cycle approach for security and privacy (NIST Special Publication 800-37, Rev. 2). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-37r2
Joint Task Force. (2020). Security and privacy controls for information systems and organizations (NIST Special Publication 800-53, Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5
Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger, L., & Leaf, D. (2011). NIST cloud computing reference architecture (NIST Special Publication 500-292). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.500-292
Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST Special Publication 800-61, Rev. 3). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r3
Preyna, D. (2026, October 23). Designing the governed cloud: Architecture, integration, and accountability. ACC3 International. https://acc3int.com/whitepapers/designing-the-governed-cloud/
Rahman, A., & Williams, L. (2019). Source code properties of defective infrastructure as code scripts. Information and Software Technology, 112, 148–163. https://doi.org/10.1016/j.infsof.2019.04.013
Souppaya, M., & Scarfone, K. (2022). Guide to enterprise patch management planning: Preventive maintenance for technology (NIST Special Publication 800-40, Rev. 4). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-40r4
Swanson, M., Bowen, P., Phillips, A. W., Gallup, D., & Lynes, D. (2010). Contingency planning guide for federal information systems (NIST Special Publication 800-34, Rev. 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-34r1
