N2SF Deliverables and Security Review

What Should Organizations Prepare for an Information Project?

Government and public-sector IT environments are changing rapidly as cloud computing, generative AI, remote work, and other technologies become increasingly common.

This change also requires a shift in cybersecurity. Instead of relying only on network separation, organizations increasingly need to identify the importance of information and the threats surrounding each information service, and then apply appropriate security controls.

The National Network Security Framework (N2SF) is designed around this approach.

The September 2025 version 1.0 guideline describes N2SF as a security framework in which organizations identify business information and information systems, classify them into three levels—Classified (C), Sensitive (S), and Open (O)—and apply security controls according to their classification.

One of the most important practical aspects of N2SF is the relationship between deliverables and security review.

1. Why Are N2SF Deliverables Important?

N2SF is not simply a process for purchasing security products.

It follows five major stages:

Prepare → Categorize → Identify → Select → Assess

The guideline explains that the results produced at each stage affect subsequent activities and are ultimately reviewed and consolidated during the Assess stage.

Therefore, the final deliverables should be viewed as more than administrative documents.

They provide documented evidence of the security decisions made during the information-service design process.

In practical terms, they should answer one important question:

"Why was this particular security measure selected?"

2. The Five N2SF Stages

① Prepare

The organization first defines the scope of the project and analyzes its business functions.

Major activities include:

• Establishing the N2SF implementation plan

• Analyzing organizational business functions

• Identifying business information

• Identifying information systems

• Identifying information services

• Defining usage scenarios

• Establishing basic security objectives

The goal is to understand what information is handled, where it is stored, how it moves, and which systems are involved.

② Categorize

Business information and information systems are classified into three security levels:

• C — Classified

• S — Sensitive

• O — Open

The classification of business information is used as a basis for determining the classification of information systems.

If an information system handles information with different security levels, the guideline provides a principle for applying the highest applicable level to the system.

This classification becomes an important part of the final security deliverable.

3. Identify: Turning the Information Service into a Threat Model

The third stage identifies potential security threats.

N2SF uses a Location–Subject–Object modeling approach to simplify complex information-service environments.

The model helps organizations identify situations in which different security levels are mixed and determine where additional security controls may be necessary.

The resulting relationship can be summarized as:

Information-service model → Security classification → Threat → Security requirement

This relationship becomes the foundation for selecting security controls.

4. Select: Connecting Threats to Security Controls

Once threats have been identified, organizations derive security requirements and select appropriate controls.

The controls may be administrative, physical, or technical.

The guideline indicates that organizations should consider factors such as:

• C/S/O priority considerations

• Characteristics of the information service

• Organizational security policies

• Applicable regulations and guidelines

• Technical environment

• Implementation feasibility

• Compatibility with existing systems

Organizations may also define additional security controls when the standard N2SF controls do not sufficiently address a particular requirement.

An implementation plan is then developed for each selected control.

This can include:

• Target systems

• Implementation method

• Product acquisition or development

• Operational requirements

• Responsible personnel

• Required resources

• Implementation schedule

5. Assess: Reviewing the Results Before Security Review

The final N2SF stage is Assess.

The organization reviews the results of the previous stages and checks whether they are appropriate and logically connected.

For example:

Business information → C/S/O classification → Threat → Security requirement → Security control → Implementation plan

should form a consistent chain.

If an inappropriate result is identified, the relevant activity and affected subsequent activities may need to be performed again.

The guideline states that final confirmation is made after all assessment items are appropriate and the necessary preparations for the security review have been completed.

6. Four Key Documents for Security Review

The N2SF guideline identifies four major documents to be submitted for security review.

① Project Plan

The project plan should describe not only the project objectives and implementation schedule but also how the security controls identified through N2SF will actually be implemented.

② Request for Proposal

The RFP should translate N2SF-derived security requirements into requirements that vendors can implement.

For example, requirements related to authentication, network separation, access control, logging, or data protection should be reflected in the RFP when applicable.

③ Network Architecture Diagram

The network diagram should show how the selected security controls are incorporated into the actual architecture.

It should allow reviewers to understand, as appropriate:

• Network zones

• Information systems

• Information services

• External connections

• Internal connections

• Security-control locations

The guideline specifically states that the network structure should reflect the security controls derived through N2SF.

7. The Core Final Deliverable: Self-Developed Security Measures

The most important consolidated N2SF deliverable is the Self-Developed Security Measures document.

The guideline describes it as a final deliverable that consolidates the results of the five major N2SF activities and provides a dedicated format for it.

Its structure includes the following major sections.

① Information-Service Security Objectives

This section defines the basic security requirements applicable to the information service.

Examples may include network separation, restricting Internet access to necessary services, or preventing simultaneous connections between specific environments.

② C/S/O Classification

Business information and information systems are organized according to their security levels.

③ Security Requirements and Security Controls

This section connects:

Threat location → Security requirement → Security control

The N2SF catalog can be used, and organization-specific controls can be added when necessary.

④ Security-Control Implementation Plan

The organization describes how each selected control will actually be implemented and operated.

The guideline's example includes:

• Security-control item

• Target

• Implementation method

• Implementation and operational requirements

• Notes

Therefore, simply stating "MFA will be implemented" is generally less informative than documenting where, how, under what conditions, and how the control will be operated.

8. Consistency Across the Deliverables Is Critical

One of the most important practical points is that the four documents should not be prepared independently.

They should represent different views of the same security design.

A useful relationship is:

Business information

↓

C/S/O classification

↓

Information system

↓

Threat identification

↓

Security requirements

↓

Security controls

↓

Implementation plan

↓

Network architecture

↓

Project Plan / RFP

↓

Self-Developed Security Measures

If these documents contain contradictory information, additional clarification or revision may be necessary during the review process.

9. Practical Points to Check

1. Document the basis for C/S/O classification

The classification should be explainable based on the information being handled and the applicable criteria.

2. Connect threats to controls

A logical sequence is:

Threat → Security requirement → Security control

rather than selecting controls first and trying to justify them afterward.

3. Make the architecture consistent with the security measures

If the self-developed security measures require network separation, the architecture diagram should show how that separation is actually implemented.

4. Reflect security requirements in the RFP

Security requirements should not exist only in an internal security document. When relevant, they should also be reflected in procurement and implementation requirements.

5. Reassess changes

Changes to systems, network architecture, or information flows can affect previously identified threats and security controls.

The N2SF guideline also states that when an information-service model is modified or expanded, affected threat-identification and security-control activities should be considered again.

10. N2SF Implementation in 2026

N2SF has moved beyond the initial guideline stage into broader practical adoption.

In 2026, the Korea Internet & Security Agency (KISA) launched an N2SF adoption support program for government and public-sector organizations. The program includes activities such as identifying N2SF targets, C/S/O classification, adjustment of assessment results, and operational planning.

KISA also published the N2SF Demonstration Casebook in April 2026. The casebook was developed from demonstrations conducted in government and public-sector environments and emphasizes that organizations should redesign the models according to their own network architecture, connected systems, and security policies.

In addition, current national information-security guidance specifies four major documents for security review—project plan, RFP, network architecture diagram, and self-developed security measures—and the 2026 revision specifies that N2SF, cloud, and AI-related projects should include applicable guideline checklists and deliverables.

This means N2SF deliverables are becoming an increasingly important part of planning and documenting security requirements for public-sector information projects.

11. N2SF Deliverable Preparation at a Glance

Step 1 — Define project scope

→ Analyze business functions

Step 2 — Identify business information and systems

→ Determine what is processed and where

Step 3 — Classify C/S/O

→ Determine information and system security levels

Step 4 — Model the information service

→ Analyze Location–Subject–Object relationships

Step 5 — Identify threats

→ Determine threats and affected locations

Step 6 — Derive security requirements

→ Define requirements for identified threats

Step 7 — Select security controls

→ Select N2SF or organization-specific controls

Step 8 — Develop implementation plans

→ Define implementation, operation, responsibility, and schedule

Step 9 — Assess and adjust

→ Review and correct the results

Step 10 — Prepare the final deliverable

→ Complete the Self-Developed Security Measures

Step 11 — Reflect the controls in project documents

→ Project Plan, RFP, and Network Architecture

Step 12 — Prepare for security review

→ Check consistency across all four documents

Conclusion

The core idea of N2SF is not simply to replace one network-security model with another.

Its central approach is to identify the importance of information, analyze the threats surrounding the information service, and apply security controls appropriate to the identified risks.

The results must then be documented.

For an information project subject to security review, the Project Plan, RFP, Network Architecture Diagram, and Self-Developed Security Measures should therefore be treated not as independent documents, but as interconnected representations of one security design.

A strong N2SF deliverable should be able to explain a consistent chain:

What information is being handled → What threats exist → What security requirements are needed → What controls were selected → How those controls will be implemented and operated.

That consistency is one of the most important principles when preparing N2SF deliverables and security-review documentation.