Designing the Governed Cloud: Architecture, Integration, and Accountability
Architecture and operating-model decisions for a defensible target state
BLUF: Cloud migration commits budget, staff time, and operating risk before a workload runs in its new location. When dependencies, ownership, and recovery are left unsettled, the move carries old problems into new infrastructure. Leaders should judge migration readiness by the decisions and evidence behind a workload rather than by whether it can be moved. This paper proposes a minimum decision record, four evidence gates, and a decision-rights allocation for making that judgment, and it closes with a 60-day pilot that tests the approach on one workload.
Audience: Chief information officers, program executives, and the architecture, security, and authorizing officials who approve cloud migration in defense and commercial organizations.
Scope: This paper stops at migration and operational handoff. Day-to-day configuration baselines, continuous monitoring, vulnerability response, incidents, and recovery operations are addressed in the companion paper, Operating the Governed Cloud: Security, Configuration, and Service Continuity (forthcoming).
Why the decision comes before the move
Cloud migration forces an organization to make decisions that often remained implicit in its existing environment. Dependencies, ownership, and recovery become visible when teams begin designing the target state. Jamshidi et al. (2013) synthesized 23 cloud-migration studies and concluded that the research was still early in maturity, identifying needs for stronger migration frameworks, architectural adaptation, and better tool support. A later survey compared published migration processes against a framework that includes requirements analysis, legacy application analysis, and target architecture design, and it identified challenges that remain open (Fahmideh Gholami et al., 2016). Neither review measures outcomes in the field. Both point to the same risk: a workload moved before those decisions are settled tends to bring its old problems with it.
A defensible cloud target state begins with mission and business needs and an explicit operating model. It identifies which systems must interact, what evidence will support security and architecture decisions, and who remains accountable once a service enters production. Hosting options matter, but they follow those commitments.
Cost belongs in that first conversation. Fernandez recommends assessing the combined cost of infrastructure, support, training, and application migration or development before treating platform choice as settled. Some organizations already have enterprise commitments that narrow their options, and he regards building on existing investments as a sound strategy. Research on enterprise cloud adoption makes a similar case for weighing cost and organizational impact alongside technical suitability (Khajeh-Hosseini et al., 2012). Existing investments belong in the same decision as the costs and constraints of the intended service.
This paper draws on two ACC3 International subject-matter experts: Stephen Fernandez, Chief Technology Officer (CTO), and Patrick Grau, Senior Technical Advisor. Each answered a structured written questionnaire prepared for this paper (S. Fernandez, personal communication, October 19, 2026; P. Grau, personal communication, October 19, 2026), and Grau also reviewed the draft decision-rights matrix in Section 7. 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 research, and neither perspective replaces a customer’s own approvals.
Fernandez’s contributions concern enterprise investment, decision authority, independent security assessment, risk acceptance, and accountability after migration. These questions matter to defense organizations and commercial enterprises alike, because architecture choices commit resources and redistribute operating risk. Grau contributes the technical scrutiny: dependency discovery, cross-boundary name resolution, deployment reproducibility, audit evidence, workload rationalization, and migration gates. His work connects design approval to what delivery and operations teams can verify.
1. Start with operational outcomes and constraints
The initial architecture conversation should establish the operational result and how leadership will know whether it improved. Depending on the service, that measure may be mission readiness, customer service, interoperability, or maintenance burden. Each outcome needs an accountable owner. Without that baseline, a migration team can move systems and still leave the organization no better equipped to perform its work.
Data classification, retention obligations, identity dependencies, recovery objectives, integration patterns, workforce capacity, and contractual boundaries shape what is feasible. Some are nonnegotiable. Others require a deliberate tradeoff. The architecture record should say which is which.
Grau recommends beginning discovery with five questions. How do users reach the service? How is entrusted information protected? How do administrators manage and validate access? How do developers maintain and update dependencies? How could the organization exit or change cloud providers? The answers should be verified against a maintained functional system architecture, a current deployment model, and a software bill of materials that makes included components and licenses visible. Current infrastructure-as-code artifacts add evidence of how the environment is built and deployed.
2. Describe the target state before selecting services
A target-state architecture should record the decisions and relationships behind the proposed service; the diagram is one part of that record. Jansen and Bosch (2005) argue that software architecture is best understood as a set of design decisions, and they connect the loss of decision knowledge to architecture erosion and high change costs. Their argument concerns software architecture generally, but it fits a cloud target state well. Workload boundaries, trust zones, data flows, integration contracts, telemetry, deployment pathways, and continuity expectations all need enough definition for later teams to verify the design. The record should also state what remains on premises or with external partners and why.
The reasoning behind a decision is the part most easily lost. Tang et al. (2006) found that 62.9% of respondents reported completely documenting design rationale. The weaker point was preserving why one option was selected over alternatives, including rejected choices; respondents who did not document rationale cited time and budget pressure and a lack of standards or process support. A record written when the decision is made keeps that rationale available when the choice is revisited. Table 1 lists what the record should contain for a significant choice, including the tradeoff criteria Grau applies. Documentation depth should follow consequence.
Table 1
A decision record should let a later team see what was chosen, by whom, and what would reopen the choice.
| Record element |
What the record should show |
| Options considered |
The alternatives evaluated, including leaving the workload where it is |
| Governing constraint |
The nonnegotiable requirement or deliberate tradeoff that drove the choice |
| Tradeoff criteria |
Time to stable operation, initial and future costs, effort to develop necessary skills, fit with the current architecture, compatibility with adjacent application components, expected product longevity, and support and security models (Grau) |
| Decision authority |
The approving authority and any material exceptions |
| Rationale |
Why the selected option was preferred against those criteria and constraints |
| Reconsideration trigger |
The condition that would reopen the decision |
Grau’s criteria do not produce a single right answer. They belong beside the nonnegotiable requirements, and the preferred option depends on the service and its operating context.
Workload placement should follow documented criteria tied to the service. Data sensitivity, latency, transaction dependencies, recovery objectives, licensing restrictions, predictable demand, and the cost of retaining connections to existing systems all affect placement. A workload may remain where it is, move with limited change, or require redesign. For some monolithic systems, redesign may be part of the placement decision. In its review of 47 studies, Hasan et al. (2023) found microservices were the most frequently targeted architectural pattern and that current migration approaches often lack quality consideration, contributing to post-migration quality concerns. Each placement choice should identify the constraint it satisfies and the evidence needed to revisit it.
The target state also has to account for shared capabilities. Identity federation, directory services, network connectivity, logging, secrets and key management, and service monitoring often span multiple workloads and organizational boundaries. Their owners, interfaces, service expectations, and funding arrangements should be established before individual teams commit to designs. A shared dependency without an accountable owner can delay several migrations at once.
External services introduce dependencies that outlast the initial migration. In a survey of mainly UK organizations, Opara-Martins et al. (2016) found vendor lock-in and data portability to be significant concerns in cloud migration decisions. The sample is largely from one country, but the concern applies wherever a supplier’s terms shape the operating model. Architecture reviews should record portability assumptions, data egress and retrieval provisions, supplier interfaces, contractual service obligations, and the effect of pricing or support changes on the operating model. Significant dependencies should be visible so leaders can accept them deliberately.
Those dependencies keep their security and privacy implications after go-live, and research offers less help with that later phase. A systematic review of security work on cloud-based scientific and business workflows found that most studies address the modeling and execution phases, while monitoring and adaptation receive little coverage (Soveizi et al., 2023). The finding describes the literature rather than practice. It is still a reason not to assume that monitoring for external dependencies will be designed by default.
Fernandez places executive accountability on architecture decisions that commit organizational budgets and resources, with the architecture and information security teams advising. The decision record should name the approving authority, record material exceptions, and separate organizational risk acceptance from technical implementation.
Application rationalization provides a basis for deciding which workloads move, change, or remain in place. Grau recommends the federal Chief Information Officer (CIO) Council’s Application Rationalization Playbook, which starts with governance and an application inventory before evaluating business value, technical fit, cost, and placement (Chief Information Officer Council, 2020). Figure 1 shows the sequence.
Figure 1
The CIO Council process settles governance and the application inventory before any placement decision.
Note. From Application Rationalization Playbook: An Agency Guide to Portfolio Management, by Chief Information Officer Council, 2020. Available through the GSA Cloud Information Center (https://cic.gsa.gov/planning/business-considerations). In the public domain.
Figure 2 uses business value and technical fit to support later portfolio decisions.
Figure 2
The rationalization matrix screens applications by business value and technical fit before placement analysis.
Note. From Application Rationalization Playbook: An Agency Guide to Portfolio Management, by Chief Information Officer Council, 2020. Available through the GSA Cloud Information Center (https://cic.gsa.gov/planning/business-considerations). In the public domain. Circle size indicates total cost of ownership per user; the plotted applications are illustrative, not ACC3 or client data.
A workload in the “refresh” quadrant can still face security, integration, contractual, or continuity constraints. High business value and technical fit do not by themselves require migration either. Placement should still be documented against the organization’s operating requirements.
3. Map integration as part of the architecture
Migration plans often concentrate on applications as individual units. Operational work rarely respects those boundaries. A transaction may depend on a legacy system, a shared identity provider, a data exchange, and an external service. The CIO Council playbook treats dependency mapping as an explicit step, asking program offices to identify upstream and downstream application dependencies as part of the assessment (Chief Information Officer Council, 2020). Mapping those interactions early exposes latency, data-quality, authentication, and failure-handling requirements that a workload inventory can miss.
Grau singles out Domain Name System (DNS) resolution that spans internal, demilitarized zone (DMZ), and external networks. Different owners may see only pieces of the name-resolution path, so validation has to cross those boundaries. He also notes that a provider’s advertised service may not be enabled in a particular tenant or organizational environment. The target-state design should verify service availability and connected transactions in the environment that will operate the workload.
Figure 3 traces DNS, identity, network policy, and cloud services across different ownership boundaries.
Figure 3
Integration dependencies cross trust boundaries that no single owner sees in full.
Note. Original ACC3 figure. Illustrative only; boundaries and service relationships vary by organization and hosting environment.
Each segment needs validation before a workload is considered ready.
4. Make security and resilience testable
Security architecture becomes testable when controls have named owners and verification methods. That requirement reaches identity and access boundaries, encryption and key stewardship, logging, vulnerability management, configuration management, incident response, and recovery. A policy statement without an owner or a way to verify implementation provides limited assurance.
For government organizations the concern is long-standing. A systematic review of 33 studies on government cloud adoption identified information security and privacy as critical barriers to adoption (Ukeje et al., 2024). Frameworks supply a common vocabulary for the response. The NIST Cybersecurity Framework 2.0 includes a Govern function and provides a cross-sector language for cybersecurity outcomes (National Institute of Standards and Technology [NIST], 2024). NIST Special Publication (SP) 800-53 Rev. 5 catalogs controls that organizations select and tailor to applicable risk and authorization requirements (Joint Task Force, 2020). Neither publication replaces the applicable approval process.
Authorization requirements depend on the organization. DoD Instruction 8510.01 requires that DoD systems be authorized under the Risk Management Framework (RMF) (Department of Defense, 2022), and the RMF assigns the decision to accept residual risk to a designated authorizing official (Joint Task Force, 2018). Commercial organizations may instead be governed by sector rules, contract obligations, and internal risk processes. In either setting, leadership should identify the responsible risk authority, the review path, and the required evidence. A successful technical deployment does not constitute risk acceptance.
Independence matters at the assessment step. Fernandez holds that technical implementers can provide information for an assessment but should not perform the analysis, because they may be reluctant to raise a difficult issue that is critical. In his words, security assessment “should be done by resources with sufficient understanding of the work but distanced from performing it.”
Grau offers a useful auditability challenge: could an independent reviewer reconstruct the creation or activation of an environment, including administrative activity, from evidence retained outside the original environment? His illustrative horizon is roughly 90 days, but that figure is not a general retention prescription. Identity controls, logging, recovery, and resilience each need agreed acceptance tests.
5. Build an operating model that survives go-live
The operating model should begin before the first workload moves. Name the service owner early and establish responsibility for provisioning, access administration, support, configuration changes, and incident escalation. Fernandez also calls for continuing risk analysis and mitigation whenever assets are promoted or data is deployed across environments that may have different policies.
The migration business case has to account for costs that continue after the move. Infrastructure consumption is one part of total cost; supplier arrangements and the effort of maintaining connected systems also count, and security adds its own recurring commitments. A systematic review of 59 studies on the economics of cloud security traced those commitments to cost-centric attacks, service disruption and recovery, and defensive overhead, and it found little longitudinal evidence on long-term costs (Filiopoulou et al., 2027). That gap argues for stating cost assumptions explicitly and reviewing them on a schedule rather than promising fixed savings. Military leaders will weigh readiness and public-resource stewardship, while commercial leaders will examine service continuity and financial exposure. Both need an agreed baseline and a named owner of the measurement.
Escalation paths should connect engineering, security, operations, and suppliers. The operating model should also name who authorizes exceptions, who measures service performance, and who funds capacity and support after project funding ends.
Grau proposes a pointed handoff test: can operations staff reproduce the environment without the original developers? Architecture and deployment descriptions, configuration records, software and license inventories, access responsibilities, and recovery procedures make that possible. Recreating a service in another cloud is one way to expose portability assumptions, although it is not a universal acceptance test. The operations team must demonstrate that it can maintain the system it inherits.
6. Sequence migration around evidence
Migration sequencing should test the hardest assumptions early. A pilot needs a baseline, mapped dependencies, designated owners, and acceptance criteria that expose weaknesses in the target design. Findings feed the next-wave decision, including a decision to defer work.
Before a pilot begins, Grau would require the team to document functional parity where parity is required, identify intended architectural differences, and show how code and deployment configuration switch between source and target environments. At exit, the team should document achieved parity, approved exceptions, improvements or regressions, and the effort required to make the change. Repeated exceptions or unexplained switching costs are reasons to revisit the next wave.
Stopping should be possible from more than one direction. Fernandez names three stakeholder groups that can pause a wave, at least temporarily: the client community, leadership, and technology platform owners. Each applies its own criteria, so the organization should designate in advance who resolves the conflict and authorizes restart. No peer-reviewed source examined for this paper tests these gate and stop-authority arrangements. They are presented here as practitioner recommendations.
Measures should show whether the service improved. Grau suggests total cost of ownership, user or customer experience where appropriate, business results, and functional-test outcomes. For AI-enabled applications, outcome-quality scoring may belong in the measure set. Fernandez adds a blunt test: if neither performance nor functional capability has improved, calling the hosting move “modernization” is difficult to defend. He would also expect organizational structure to change to match the new architecture. That expectation is consistent with research showing that software architectures tend to mirror the structure of the organizations that build them (MacCormack et al., 2012), although that work documents the correspondence rather than prescribing restructuring.
Figure 4 concentrates these decisions at four gates. Progress should stop at any gate when evidence is incomplete or when the responsible authority has not accepted the remedy for a failed test, unresolved exception, or incomplete handoff.
Figure 4
Each migration gate requires named evidence and an accountable decision before work advances.
Note. Original ACC3 figure, a conceptual framework based on the decision and verification criteria discussed in this paper. The stop-and-rework condition applies at every gate, not only at review.
7. Assign decision rights and evidence
Table 2 assigns provisional owners and evidence to the decisions made before migration and handoff. Grau’s review added the transfer of user knowledge and access, including identity and access management (IAM) validation during transition. Fernandez made no changes when he reviewed the matrix separately; his broader guidance places budget and resource accountability with executives and security assessment with independent reviewers.
Table 2
Each pre-migration decision needs an evidence set and an accountable role before a wave begins.
| Decision domain |
Required evidence |
Accountable role (to confirm) |
| Operational outcome |
Baseline, success measure, constraints |
Mission or business service sponsor |
| Architecture and integration |
Target-state diagrams, dependency map, decision record |
Architecture authority |
| Security and risk |
Control mapping, independent test results, transition IAM/access validation, exception record |
Security/risk authority |
| Operational readiness |
Runbooks, recovery tests, monitoring, user/access transfer, knowledge handoff |
Service/operations owner |
| Migration wave approval |
Acceptance results, residual risk, rollback plan |
Designated change authority |
Before a migration wave begins, each row needs a specific person or approval body, with the listed evidence attached to the decision record. One person may fill more than one role, but the record should show which decision that person is authorized to make. Each organization must designate its own approval authorities.
8. Carry architecture decisions into governed delivery
ACC3’s published description of Alchemist AI Pro™ offers a starting point for a bounded cloud-architecture discovery effort. ACC3 describes the requirements engine as drawing on stakeholder knowledge and existing system material, guiding elicitation and elaboration, surfacing gaps and conflicting assumptions for human review, and producing requirements, specifications, use cases, acceptance criteria, and testing material (Edwards, 2026; Preyna, 2026a). Applied to one proposed migration, those artifacts could document service users, IAM obligations, integration dependencies, architecture constraints, operational ownership, and unresolved decisions.
Human review stays in the loop. Mendoza et al. (2026) evaluated ARTEMIS on five real-world safety-critical requirements datasets and reported 1.57× higher translation accuracy while reducing manual validation effort by up to 10.83× compared with state-of-the-art baselines. The study concerns safety-critical temporal-logic requirements rather than cloud architecture, but it reinforces the need to validate machine-generated formalizations before they become an approved baseline. Architecture authorities and system owners should validate technical conclusions and approve that baseline.
ACC3 designs Alchemy SDLC™ to carry the approved specification into a governed software-delivery record. ACC3 describes traceability between requirements, build activities, test evidence, acceptance decisions, and later change, with people retaining approval authority (Preyna, 2026b). The underlying problem is an old one. Gotel and Finkelstein (1994) found that most requirements traceability problems arise from poor links back to where requirements came from and the stakeholders behind them.
ACC3’s published account of an internal customer relationship management (CRM) effort records feature-level links through implementation and user acceptance (Preyna, 2026b). That account is ACC3’s own process observation, drawn from an internal case record, and because it concerns an internal CRM it does not establish cloud-migration outcomes. For a migration, the same discipline can connect an agreed design or application change with implementation and verification. Infrastructure deployment, security authorization, cross-cloud portability, and operational transfer require their own technical evidence and authorized decisions.
Evidence note: Fernandez also raised semantic drift and token consumption as topics for scrutiny. The studies he identified describe those problems; none examines an ACC3 product. The most relevant, a preprint, found that agentic coding tasks consumed far more tokens than chat-based code assistance, and that cost varied widely and was difficult to predict before execution (Bai et al., 2026). A responsible assessment would measure requirement accuracy, review effort, and token consumption against a defined baseline before ACC3 makes quantitative claims.
A 60-day pilot
Do not choose the easiest workload. Select one service with at least one cross-boundary dependency, such as name resolution or identity federation that spans internal and external networks, and run it through the four gates in Figure 4 within 60 days. Name the sponsor, architecture authority, security or risk authority, and operations owner from Table 2 before the entry gate, and open a decision record (Table 1) for each significant choice.
The success test is Grau’s handoff test. An operations team that did not design the environment should be able to reproduce it from the record without the original developers. An independent reviewer should be able to reconstruct the environment’s creation, activation, and administrative activity from evidence retained outside it. Record where either test fails, which decisions lacked an owner, and which exceptions recurred. Those findings should decide whether the next wave proceeds.
A pass gives leadership a tested pattern for the next wave. A failure shows where the architecture record is incomplete, at the cost of one workload.
Getting Started with ACC3 International
ACC3 International recommends a focused working session with your architecture, security, and operations leads or designated staff representatives. The session selects the pilot workload, names the provisional decision owners, and opens the first decision record.
Doug Preyna | ACC3 International
Contact: https://www.acc3int.com/contact/
References
Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., & Pei, J. (2026). How do AI agents spend your money? Analyzing and predicting token consumption in agentic coding tasks (arXiv:2604.22750) [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2604.22750
Chief Information Officer Council. (2020). Application rationalization playbook: An agency guide to portfolio management (Version 1.1). GSA Cloud Information Center. https://cic.gsa.gov/planning/business-considerations
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
Edwards, N. (2026, June 16). The growing cost of DoD requirements: How requirements debt is defeating government software modernization before a line of code is written. ACC3 International. https://acc3int.com/whitepapers/growing-cost-of-requirements/
Fahmideh Gholami, M., Daneshgar, F., Low, G., & Beydoun, G. (2016). Cloud migration process—A survey, evaluation framework, and open challenges. Journal of Systems and Software, 120, 31–69. https://doi.org/10.1016/j.jss.2016.06.068
Filiopoulou, E., Dede, G., Evangelatos, S., Kamalakis, T., Michalakelis, C., & Nikolaidou, M. (2027). The economic dimensions of cloud security: A systematic literature review. Computers & Security, 172, Article 105139. https://doi.org/10.1016/j.cose.2026.105139
Gotel, O. C. Z., & Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. In Proceedings of IEEE International Conference on Requirements Engineering (pp. 94–101). IEEE. https://doi.org/10.1109/ICRE.1994.292398
Hasan, M. H., Osman, M. H., Admodisastro, N. I., & Muhammad, M. S. (2023). Legacy systems to cloud migration: A review from the architectural perspective. Journal of Systems and Software, 202, Article 111702. https://doi.org/10.1016/j.jss.2023.111702
Jamshidi, P., Ahmad, A., & Pahl, C. (2013). Cloud migration research: A systematic review. IEEE Transactions on Cloud Computing, 1(2), 142–157. https://doi.org/10.1109/TCC.2013.10
Jansen, A., & Bosch, J. (2005). Software architecture as a set of architectural design decisions. In 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05) (pp. 109–120). IEEE. https://doi.org/10.1109/WICSA.2005.61
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
Khajeh-Hosseini, A., Greenwood, D., Smith, J. W., & Sommerville, I. (2012). The Cloud Adoption Toolkit: Supporting cloud adoption decisions in the enterprise. Software: Practice and Experience, 42(4), 447–465. https://doi.org/10.1002/spe.1072
MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309–1324. https://doi.org/10.1016/j.respol.2012.04.011
Mendoza, D., Mavridou, A., Katis, A., & Trippel, C. (2026). Automating requirements formalization: Using LLMs and low-complexity distinguishing traces for semantic validation. In Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering (pp. 1314–1326). https://doi.org/10.1145/3744916.3787815
National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0 (NIST Cybersecurity White Paper 29). https://doi.org/10.6028/NIST.CSWP.29
Opara-Martins, J., Sahandi, R., & Tian, F. (2016). Critical analysis of vendor lock-in and its impact on cloud computing migration: A business perspective. Journal of Cloud Computing, 5(1), Article 4. https://doi.org/10.1186/s13677-016-0054-z
Preyna, D. (2026a, July 2). From vibe coding to governed delivery: Why AI-assisted software still requires an SDLC. ACC3 International. https://acc3int.com/whitepapers/from-vibe-coding-to-governed-delivery/
Preyna, D. (2026b, August 9). Governance first: Controlling the path from AI-assisted requirements to production code. ACC3 International. https://acc3int.com/whitepapers/governance-first/
Soveizi, N., Turkmen, F., & Karastoyanova, D. (2023). Security and privacy concerns in cloud-based scientific and business workflows: A systematic review. Future Generation Computer Systems, 148, 184–200. https://doi.org/10.1016/j.future.2023.05.015
Tang, A., Babar, M. A., Gorton, I., & Han, J. (2006). A survey of architecture design rationale. Journal of Systems and Software, 79(12), 1792–1804. https://doi.org/10.1016/j.jss.2006.04.029
Ukeje, N., Gutierrez, J., & Petrova, K. (2024). Information security and privacy challenges of cloud computing for government adoption: A systematic review. International Journal of Information Security, 23(2), 1459–1475. https://doi.org/10.1007/s10207-023-00797-6
