1. Why Cloud Adoption Type Matters

When an organization decides to move to the cloud, the first question is often:

"Which cloud provider should we use?"

For national and public institutions, however, another question comes first:

"What type of cloud adoption model should we use?"

The National Cloud Computing Security Guidelines (January 2023) classify cloud adoption for national and public institutions into five major types:

1. On-site Private Cloud

2. On-site Community Cloud

3. Outsourced Cloud

4. Hybrid Cloud

5. Multi-Cloud

The fundamental differences are based on several questions:

• Who builds the cloud?

• Who operates it?

• Who controls the cloud resources?

• Are resources shared with other institutions?

• Does the cloud need to connect with existing information systems?

• Are multiple cloud services connected?

The guideline presents these five models as the main adoption types in Chapter 3, Section 1.

2. Five Models at a Glance

The guideline defines these models primarily according to the organization of resource control and sharing.

3. Model 1: On-site Private Cloud

3.1 What is it?

An On-site Private Cloud is a model in which an institution builds and directly manages its own cloud environment and uses the cloud resources exclusively for itself.

The guideline describes this model as suitable for institutions that use independent networks, handle highly sensitive information, or cannot easily share IT resources with other institutions.

A simplified structure looks like this:

[Government Institution]
          │
          ▼
┌─────────────────────┐
│ Institution Cloud   │
│                     │
│ Virtual Servers     │
│ Virtual Storage     │
│ Virtual Network     │
│ Virtual Desktops    │
└─────────────────────┘
          │
          ▼
   Business Systems

3.2 Key characteristics

The institution retains direct control over:

• Cloud infrastructure

• Network

• Virtual resources

• Security configuration

• Access control

• Operations

The guideline identifies several security considerations, including locating the network within the institution, allowing external access through dedicated lines or encrypted communication such as VPN, and deploying information security systems between internal and external networks.

3.3 When should it be considered?

This model may be considered when:

• The institution handles highly sensitive systems.

• Independent networks are required.

• Sharing resources with other institutions is difficult.

• Direct control over cloud resources is particularly important.

The major trade-off is straightforward:

More institutional control also means more institutional responsibility.

4. Model 2: On-site Community Cloud

4.1 What is it?

An On-site Community Cloud allows multiple institutions with similar business characteristics or network environments to share cloud resources within a defined community.

For example:

              ┌─────────────────┐
              │ Lead Institution │
              │ Cloud Platform   │
              └────────┬────────┘
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
         Institution A B       Institution C
             │         │         │
             └──── Community ────┘

The guideline explains that this model can be considered when institutions have similar business characteristics, can share IT resources, and may find it difficult to independently build and manage cloud environments.

Resources may be shared among community members, but not with institutions outside the community.

4.2 Why use this model?

Potential benefits include:

• Shared infrastructure investment

• Shared operational capabilities

• Better utilization of computing resources

• Common cloud environments for similar institutions

However, "shared" does not mean "unrestricted access."

The guideline calls for access controls between community resources, secure communications between institutions, and security systems between institutional networks and the community cloud.

Therefore, the key principle is:

Share resources, but maintain security boundaries.

5. Model 3: Outsourced Cloud

5.1 What is it?

An Outsourced Cloud is a model in which the institution uses a cloud environment operated by an external, typically private-sector, cloud provider.

The guideline describes this model as appropriate for institutions for which building and operating an independent cloud environment may be inefficient or difficult.

In this model, IT resources are located within the provider's network, which means the institution has less direct control over the underlying infrastructure.

5.2 Basic architecture

[Public Institution]
        │
  Dedicated Line /
      VPN
        │
        ▼
┌─────────────────────────┐
│ Cloud Service Provider  │
│                         │
│ Public-sector Area      │
│ ┌──────┐  ┌──────┐      │
│ │ Org A│  │ Org B│ ...  │
│ └──────┘  └──────┘      │
└─────────────────────────┘

The guideline calls for public-sector areas to be separated from private/general areas, secure communication between the institution and cloud provider, and security systems such as intrusion detection for external Internet connections.

5.3 What should an institution verify?

A public institution should not select a cloud service solely based on:

• Price

• CPU or storage performance

• Convenience

• Number of available services

It should also examine:

• Eligibility for public-sector use

• Security certification and applicable adoption requirements

• Separation between public-sector and general-user environments

• Data storage and management location

• Security monitoring

• Incident investigation capabilities

• Logging and auditing

• Backup and recovery

• Administrative access control

• Contractual security responsibilities

In Korea, KISA operates the Cloud Security Assurance Program (CSAP), which evaluates and certifies whether cloud services meet defined information-security requirements. Its scope includes cloud services such as IaaS, PaaS, and SaaS.

Because certification requirements and guidance can change, institutions should verify the latest requirements when starting an actual project. KISA continues to publish updated CSAP guidance and related materials.

6. Model 4: Hybrid Cloud

6.1 Why is Hybrid Cloud important for government institutions?

Government institutions often cannot migrate every existing system to an external cloud at once.

Some systems may need to remain inside institutional networks, while other services may benefit from cloud scalability and flexibility.

A Hybrid Cloud connects existing institutional information systems with external cloud services.

The guideline describes this model as a way to maintain existing information systems while taking advantage of cloud computing. It can also allow institutions to maintain security control over highly sensitive data while using cloud services for other workloads.

6.2 Simplified architecture

             ┌─────────────────────┐
             │ Internal Systems    │
             │ Sensitive Data      │
             └──────────┬──────────┘
                        │
                   Security
                   Controls
                        │
                  Dedicated Line /
                       VPN
                        │
                        ▼
             ┌─────────────────────┐
             │ External Cloud      │
             │ Services            │
             └─────────────────────┘

6.3 The connection point is critical

One of the most important security issues in hybrid cloud is the connection point between the internal information system and the external cloud.

The guideline emphasizes strong security controls at this interface and calls for dedicated lines or encrypted communications such as VPN. It also identifies security solutions for data exchange and intrusion detection, as well as measures to prevent important internal information from being leaked through the connection point.

A useful way to remember this is:

In a hybrid cloud, securing the connection between environments can be just as important as securing the environments themselves.

7. Model 5: Multi-Cloud

7.1 What is Multi-Cloud?

A Multi-Cloud model connects and uses two or more external cloud services.

For example:

                  [Institution]
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
         Cloud A    Cloud B    Cloud C
          IaaS        PaaS        SaaS
             └─────────┼─────────┘
                       │
                 Integrated
                  Operations

The guideline describes multi-cloud as a model in which an institution connects multiple outsourced cloud environments.

It allows multiple IaaS environments and multiple PaaS/SaaS services to be operated flexibly, while cloud providers may offer APIs and other interoperability mechanisms for integration.

7.2 Why use multiple clouds?

A multi-cloud architecture can allow different services to be assigned to different cloud environments.

For example:

• Cloud A → Computing

• Cloud B → Data analytics

• Cloud C → SaaS

• Internal environment → Highly sensitive information

However, using more clouds also means more:

• Network connections

• APIs

• Credentials

• Security policies

• Logs

• Management consoles

• Data-transfer paths

Therefore, multi-cloud can increase operational complexity.

7.3 Security requirements

The guideline calls for:

• Separation of public-sector areas from private/general areas

• Dedicated lines or encrypted communication between institutions and cloud services

• Security systems at Internet connection points

• Dedicated or encrypted communication between external cloud services

• Security systems such as intrusion detection at cloud-to-cloud connection points

In other words:

Security must be considered not only for each cloud but also for the connections between clouds.

8. The Easiest Way to Distinguish the Five Models

Public-sector IT managers do not need to memorize every technical detail.

Ask these four questions.

Question 1: Who builds the cloud?

Institution → On-site model

External provider → Outsourced model

Question 2: Who controls the resources?

Institution → Greater direct control

Provider → Greater provider operational responsibility

Question 3: Are resources shared?

No → On-site Private

Within a defined community → On-site Community

Across provider infrastructure → Outsourced

Question 4: Does it connect to other environments?

Existing internal systems + external cloud → Hybrid

Multiple cloud services → Multi-Cloud

9. Practical Decision Process for Public Institutions

A practical cloud adoption review can follow these steps.

Step 1. Classify the importance of the system and data

The first question should not be:

"Can we use cloud?"

Instead ask:

"How important are this system and its data, and what level of protection is required?"

The guideline separately addresses cloud-area classification and system-importance classification in Chapter 3, Sections 2 and 3.

Step 2. Determine whether direct institutional control is necessary

Ask:

"If a major security incident or failure occurs, does the institution need direct control over the cloud resources?"

If yes, an institution-built model may need to be considered.

Step 3. Determine whether institutions can share resources

If several institutions have similar requirements and can securely share infrastructure, a community cloud may be considered.

Step 4. Evaluate external cloud services

If operating a private cloud is inefficient, an outsourced cloud can be considered.

The key point is to evaluate security and public-sector eligibility together with performance and cost.

Step 5. Check whether existing systems must remain

If legacy systems must continue operating while selected workloads move to cloud, a hybrid model can be considered.

Step 6. Determine whether multiple cloud providers are needed

If different cloud services are required for different workloads, a multi-cloud model can be considered.

10. The Most Important Issue: Security Responsibility

One of the most important concepts in government cloud adoption is the boundary of security responsibility.

Using a cloud service does not mean that every security responsibility automatically moves to the cloud provider.

For example:

Institution
 ├─ User accounts
 ├─ Access permissions
 ├─ Business data
 ├─ Application configuration
 └─ Internal connections

           ↕
   Contract / Technical
       Controls

Cloud Provider
 ├─ Physical infrastructure
 ├─ Facilities
 ├─ Virtualization
 ├─ Cloud operations
 └─ Service infrastructure

The exact responsibility boundary depends on the service and architecture.

Therefore, contracts and project specifications should clearly define:

• Who manages user accounts?

• Who manages administrator privileges?

• Who retains logs?

• Who investigates security incidents?

• Who performs backups?

• Who restores data?

• Who handles vulnerabilities and patches?

• Who is responsible for service recovery?

• What happens to data when the contract ends?

This is particularly important in outsourced, hybrid, and multi-cloud environments.

11. Do Not Confuse Cloud Adoption Type with CSAP

A common misunderstanding is:

"If a cloud service has CSAP certification, it can automatically be used for every public-sector workload."

That is not a sufficient way to evaluate a public cloud project.

CSAP is a security certification system for cloud services. KISA explains that its certification covers cloud services such as IaaS, PaaS, and SaaS and evaluates compliance with defined security requirements.

By contrast, the five adoption models in the National Cloud Computing Security Guidelines describe the architecture and operating structure:

• Institution-built

• Community-based

• Outsourced

• Hybrid

• Multi-cloud

Therefore, an actual public-sector project needs to consider multiple layers:

Adoption model → System importance → Cloud area → Security requirements → Provider/service verification → Security review

This distinction is essential for practical project planning.

12. Seven Points Public-Sector IT Managers Should Remember

1. Choose the architecture before choosing the provider

The first decision is not "Which provider?"

It is:

"What cloud structure fits this system?"

2. Resource control matters

Institution-built models provide greater direct institutional control, while outsourced models place more infrastructure operation with the provider.

3. Sharing requires separation

Community clouds share infrastructure, but access and institutional resources must remain properly separated.

4. Hybrid cloud requires strong controls at connection points

The interfaces between internal systems and external cloud services are important security boundaries.

5. Multi-cloud requires cloud-to-cloud security

Each cloud can have strong security controls while the connections between them still create security risks.

6. Security responsibilities must be documented

Do not rely on the assumption that the provider "takes care of security."

7. Always check current requirements

The January 2023 guideline is an important reference, but actual projects should also verify the latest requirements, policies, laws, certification rules, and security guidance available when the project begins. KISA continues to update CSAP-related guidance and programs, including materials published in 2025 and 2026.

13. Conclusion

For national and public institutions, cloud adoption is not simply a question of whether to use cloud technology.

The more important questions are:

What workloads should be placed in the cloud?
Who controls the resources?
Which resources can be shared?
How should internal systems connect to the cloud?
Who is responsible for each security control?

The National Cloud Computing Security Guidelines (January 2023) organize these considerations into five major adoption models:

• On-site Private Cloud

• On-site Community Cloud

• Outsourced Cloud

• Hybrid Cloud

• Multi-Cloud

The practical value of these models is not simply in memorizing their names. Their real value is in understanding the differences in:

control, resource sharing, security responsibility, connectivity, and operational structure.

For an actual government cloud project, the adoption model should then be considered together with system importance and cloud-area classification. The guideline addresses these areas in the following sections of Chapter 3.

In short:

The goal of public-sector cloud adoption is not to select the most advanced cloud technology, but to design a cloud architecture that matches the importance of the workload and its security requirements.

This article is an original explanatory work based on the National Cloud Computing Security Guidelines (January 2023) and publicly available information from relevant government and certification authorities. It does not reproduce the source materials verbatim. For actual projects, the latest applicable laws, security policies, adoption requirements, certification status, and institutional security policies should be checked separately.