Security Review under Korea's National Cybersecurity Basic Guideline

A Practical Guide for Information Project Managers in Korean Government and Public Institutions

One-line Summary
Security review is a pre-procurement security process that assesses whether the security measures of an information project are appropriate and requires necessary improvements before the project is publicly announced.

1. What Is a Security Review?

When a Korean government agency or public institution plans to build a new information system, establish a network, introduce cloud services, or connect systems with other organizations, security should be considered before the project is launched.

The National Cybersecurity Basic Guideline, revised on May 1, 2026, establishes a dedicated section on security review under Chapter 2, "Security of Information Projects."

In simple terms, a security review asks:

"Can this information project be implemented as planned while adequately protecting government information, information systems, and networks?"

Article 14 requires institutions to conduct the security review during the project planning stage, before the project announcement. Written review is the basic method, although an on-site inspection may also be conducted when necessary.

Therefore, security review should not be understood as an inspection performed after a system has already been designed. It is a mechanism for incorporating security requirements into the project from the beginning.

2. The Most Important Rule: Review Before the Project Announcement

For information project managers, the timing of the review is one of the most important points.

The recommended workflow is:

Project planning

↓

Preparation of the project plan

↓

Identification of security requirements

↓

Preparation of security measures

↓

Security review

↓

Modification and supplementation of security measures

↓

Finalization of the RFP

↓

Project announcement

↓

Contract and implementation

The guideline explicitly places the review at the planning stage, before the project announcement.

This prevents situations in which a security problem is discovered after procurement has already begun.

For example, a review may identify:

• insufficient external access controls;

• inappropriate cloud architecture;

• inadequate protection of personal information;

• insufficient inter-agency connection controls;

• network architecture problems; or

• additional security requirements for an AI system.

If such issues are discovered after the project has already been announced, modifying the RFP or project design can become difficult.

The key principle is therefore:

Security review is security by design before procurement, not merely a post-implementation inspection.

3. Which Organization Conducts the Review?

Not every information project is reviewed by the same organization.

Article 15 divides review responsibilities according to the importance and characteristics of the project.

Depending on the project, security review may be conducted by:

• the National Intelligence Service (NIS);

• a superior organization; or

• an institution under an applicable delegated review framework.

The NIS may also delegate review authority to a superior organization depending on the scale and importance of a project.

4. Major Projects Subject to NIS Security Review

The 2026 guideline identifies a broad range of projects subject to NIS security review.

Major examples include:

① N2SF Projects

Projects applying the National Network Security Framework (N2SF), including the establishment of N2SF information-service models.

This is particularly important because N2SF was explicitly incorporated into the 2026 revision.

② Projects Using Approved Cryptographic Materials

Projects that establish networks or information systems using cryptographic materials developed or security-verified by the NIS.

③ National-Security-Related Systems

Information networks or systems important to national security, including diplomatic and defense-related systems.

④ Large-Scale Processing of Sensitive or Unique Identifying Information

Information systems processing sensitive information or unique identifying information under the Personal Information Protection Act for more than one million individuals.

⑤ Critical Information Infrastructure

Projects involving information and communications infrastructure that may need to be designated as critical information infrastructure.

⑥ Control Systems

Projects introducing control systems covered by the guideline.

⑦ National Crisis Management

Networks or information systems related to:

• disaster management;

• public safety;

• public security;

• emergency preparedness; and

• national crisis management.

⑧ Shared Government Networks and Systems

Networks or systems jointly used by multiple organizations.

⑨ National-Level Databases

Major national databases involving administrative information, geographic information, environmental information, and similar data.

⑩ International Events

Networks and information systems established for international events such as summits and international conferences.

5. New Areas to Watch in the 2026 Revision

The May 2026 revision is particularly relevant to today's information environment.

The review targets include projects involving:

• N2SF;

• private cloud computing services;

• inter-organizational system connections;

• large-scale backup and disaster recovery centers;

• online maintenance during national disasters or crises;

• information networks or systems using artificial intelligence; and

• space-system-related projects.

This means that information project managers can no longer determine whether security review is necessary simply by asking whether the project is a conventional IT system.

They should also ask:

• Does the project use cloud computing?

• Does it use AI?

• Does it connect to another organization's network?

• Does it process large volumes of sensitive information?

• Is it related to national crisis management?

• Does it apply N2SF?

• Does it involve a large-scale backup or disaster recovery environment?

6. Projects Reviewed by Superior Organizations

Separate from the projects reviewed by the NIS, superior organizations may conduct security reviews for projects such as:

• websites and web-based information systems;

• webmail systems;

• Internet telephone systems;

• Open-domain systems;

• vulnerability analysis and cybersecurity consulting projects;

• video conferencing systems;

• video information processing equipment;

• backup systems;

• public-facing call-center systems; and

• other networks or information systems considered necessary by the organization's head.

The guideline also allows superior organizations to establish predefined review criteria for repeatedly requested project types.

This can be particularly useful for organizations supervising many subordinate institutions.

7. When Can Security Review Be Omitted?

Security review is not necessarily required for every project.

Article 16 allows the review process to be omitted for certain categories.

However, an important principle applies:

Omitting the formal review does not mean omitting security measures.

Even when the review is omitted, the institution must establish and implement its own security measures and comply with relevant manuals and guidelines.

8. Examples of Projects Eligible for Omission

The guideline allows omission for certain types of projects, including:

Simple equipment or material purchases

Projects that do not fall within the Article 15 review categories and involve simple equipment or material procurement.

Simple follow-up maintenance

For an information project that has already completed a security review, certain follow-up activities may be omitted from another review when the network configuration is not changed.

Examples include:

• replacement of obsolete servers, storage systems, and network equipment;

• replacement of old telephones, radios, and CCTV equipment;

• replacement of an existing security system with another system providing equivalent security functions; and

• certain follow-up procedures such as vendor changes or expiration of rental periods.

Multi-year projects

A multi-year project may be exempt from repeated reviews when:

• the initial project completed a security review; and

• the project content has not changed.

Simple PC, printer, and commercial software purchases

Simple purchases, replacements, license extensions, or changes in the number of users may also fall within the omission provisions.

However, the key word is "simple."

A simple license renewal is very different from introducing a new business system.

9. The Key Question: Has the Security Environment Changed?

One of the most useful practical principles is:

Do not judge solely by whether equipment has been replaced. Check whether the network architecture, information flow, or security environment has changed.

For example:

Old server → new server with the same architecture

may be a simple replacement.

But:

Old internal server → cloud environment + external connection

is a fundamentally different security situation.

Similarly:

Existing system → same system

may be routine maintenance.

But:

Existing system → addition of AI functionality + external AI service

requires a new security assessment of the changed environment.

10. What Documents Must Be Submitted?

Article 17 identifies four major categories of documents.

① Project Plan

The project plan should include the project purpose and implementation plan.

A useful project plan should clearly explain:

• what is being built;

• why it is being built;

• who will use it;

• what information it will process;

• which organizations it will connect to; and

• the expected implementation schedule.

② Request for Proposal

The RFP should contain the security requirements that vendors must satisfy.

This is important because the requirements identified during security review need to flow into procurement and project execution.

③ Network Architecture Diagram

A network architecture diagram should be submitted, with an IP address structure where necessary.

A practical diagram should clearly show:

• user zones;

• servers;

• network zones;

• security devices;

• Internet connections;

• external organizations;

• cloud connections;

• major information systems; and

• major data flows.

④ Internal Security Measures

The institution must submit its own security measures.

The 2026 revision specifically states that N2SF, cloud, and AI-related information projects should include the relevant security guideline checklists and deliverables.

This is an important change for modern public-sector information projects.

11. How Should Internal Security Measures Be Prepared?

A practical structure is to divide the measures into three basic categories.

Administrative Security

Examples:

• security responsibilities;

• project roles;

• contractor security management;

• access-right management;

• security education;

• incident response procedures; and

• deliverable management.

Physical Security

Examples:

• server-room access control;

• equipment entry and exit management;

• removable-media management;

• facility access control; and

• backup facility protection.

Technical Security

Examples:

• network access control;

• authentication and account management;

• encryption;

• logging;

• vulnerability management;

• malware protection;

• data protection;

• security monitoring; and

• backup and recovery.

For cloud, AI, or N2SF projects, the relevant specialized security requirements should also be incorporated.

12. What Happens After the Review?

The security review does not end when the review report is received.

Article 18 requires the institution to supplement its security measures by reflecting the review results.

The reviewing organization may also conduct an on-site inspection to verify whether the review results have actually been implemented.

The practical process is therefore:

Security review

↓

Review results

↓

Action plan

↓

Security improvement

↓

Implementation evidence

This is an important distinction.

Simply storing the review report is not sufficient.

13. A Practical Way to Manage Review Findings

A simple action-tracking table can be useful:

This makes it easier to demonstrate that review findings were actually implemented.

14. Annual Management of Security Review Status

Article 19 requires superior organizations to submit information on the previous year's security review results for their own and subordinate organizations to the NIS by January 25 each year, subject to the provisions specified in the guideline.

Therefore, organizations should maintain an internal security-review register containing items such as:

• project name;

• responsible department;

• project period;

• project type;

• whether a review was required;

• reviewing organization;

• review date;

• review result;

• major corrective actions;

• implementation status;

• evidence; and

• reason for omission, if applicable.

This makes annual reporting and internal audits much easier.

15. A 10-Step Practical Checklist

Information project managers can use the following workflow.

Step 1. Determine the nature of the project

Is it merely a product purchase, or is it an information project?

Step 2. Define the project environment

Identify the systems, networks, users, data, and connected organizations.

Step 3. Identify information sensitivity

Determine what types of information the system will process.

Step 4. Check Article 15

Determine whether the project falls under NIS or superior-organization review categories.

Step 5. Check Article 16

Determine whether the project qualifies for omission.

Step 6. Prepare internal security measures

Develop administrative, physical, and technical security measures.

Step 7. Prepare the required documents

Prepare:

• project plan;

• RFP;

• network architecture diagram; and

• internal security measures.

Step 8. Complete the review before announcement

Build sufficient time into the procurement schedule.

Step 9. Implement review findings

Track each finding through corrective action and completion.

Step 10. Maintain evidence and status

Keep review records, corrective-action evidence, and annual status information.

16. Common Mistakes

Mistake 1: Reviewing after procurement

The guideline requires the review during the planning stage, before the project announcement.

Mistake 2: Assuming "omission" means "no security"

It does not.

The institution must still establish and implement its own security measures.

Mistake 3: Treating every equipment replacement as exempt

The actual network and security architecture must be considered.

Mistake 4: Assuming an existing system never needs reassessment

Cloud migration, AI integration, external connections, major data expansion, or network changes can alter the security characteristics of the project.

Mistake 5: Treating the review report as the final step

The review findings must be reflected in the actual security measures.

17. Why Security Review Matters More in the AI and Cloud Era

Modern public-sector systems increasingly combine:

• cloud computing;

• AI;

• external APIs;

• inter-agency data sharing;

• large-scale databases;

• remote maintenance;

• disaster recovery; and

• connected infrastructure.

The 2026 revision reflects this changing environment by explicitly including N2SF, cloud services, inter-organizational connections, AI systems, large-scale backup and disaster recovery, and space systems among relevant security-review areas.

For AI projects in particular, managers should ask:

• What data will the AI system process?

• Will information be sent to an external AI service?

• Where will models and training data be stored?

• How will user prompts and outputs be protected?

• How will the AI system connect to internal networks?

• How will administrator privileges be controlled?

The security review should therefore begin with the architecture and data-flow design rather than being treated as a final compliance activity.

18. The Simplest Way to Understand Security Review

For public-sector information project managers, the concept can be summarized as follows:

Security review is a pre-procurement process for identifying security risks and incorporating appropriate security measures into an information project's plan and RFP.

Remember these six points:

1. Conduct it before the project announcement.

2. Determine the appropriate reviewing organization and review category.

3. Check whether the project qualifies for omission.

4. Prepare the project plan, RFP, network diagram, and internal security measures.

5. Reflect the review findings in the actual project.

6. Maintain the review results and implementation evidence.

19. Conclusion

Security review should not be viewed simply as an administrative procedure that delays an information project.

It is better understood as a preventive security mechanism that identifies security requirements at the planning stage and reduces the risk of expensive redesign and security problems later in the project lifecycle.

The 2026 revision of the National Cybersecurity Basic Guideline is especially significant because it reflects today's changing technology environment, including N2SF, cloud computing, AI, inter-organizational connections, large-scale disaster recovery, and other emerging technologies.

For information project managers, the most useful questions to ask at the beginning of every project are:

What information will be processed?

Which network will it use?

Who will access it?

Will it connect to another organization?

Will cloud services be used?

Will AI be used?

Will the project change the environment covered by an existing security review?

Answering these questions early can make the entire security-review process much more effective.