A Practical Guide to Security Conformity Verification for Government Information Systems
This guide explains the security conformity verification process for security-enabled ICT products used by Korean government and public organizations, covering scope, application, documentation, testing, vulnerability remediation, and post-deployment management.
Security Conformity Verification for Government Information Systems
A Practical Guide Based on the National Cybersecurity Basic Guidelines
When a Korean government agency or public organization introduces an ICT product with security functions, simply purchasing and installing the product is not always sufficient.
For security-enabled ICT products, the organization needs to consider whether the product is subject to Security Conformity Verification, whether other certification or confirmation requirements apply, and whether the product can safely perform its intended security functions in the actual operating environment.
The National Cybersecurity Basic Guidelines establish these requirements in Section 5, “Security Conformity Verification.”
1. What is Security Conformity Verification?
In simple terms, Security Conformity Verification can be understood as:
A process for confirming whether an ICT product with security functions can be safely introduced and operated in a government or public-sector environment.
Article 31 of the attached guideline states that when an organization introduces an ICT product with security functions, it must undergo security conformity verification to confirm safety before actual application and operation.
The practical questions for an information-system project manager are therefore:
Does the product provide security functions?
Is the product subject to Security Conformity Verification?
Does another certification or security confirmation requirement apply?
Are the required security functions actually implemented?
Does the certification or verification scope match the actual product model and version?
Could future configuration or purpose changes require additional verification?
2. Who Applies for Verification?
Under Article 32, an organization seeking Security Conformity Verification may apply to the Director of the National Intelligence Service. The revised guideline also specifies that the Ministry of National Defense may conduct verification itself.
In practice, successful verification requires cooperation among three groups.
Project Manager
Identifies the product
Includes security requirements in the RFP
Manages vendor documentation
Coordinates verification activities
Information Security Officer
Reviews whether verification is required
Reviews security requirements
Supports the application
Reviews remediation measures
Vendor
Provides security-function documentation
Provides implementation specifications
Supports testing
Provides technical information
Addresses identified vulnerabilities
3. What Products May Be Subject to Verification?
The requirement is not intended to cover every IT product.
The guideline focuses on ICT products with security functions.
Examples may include:
Firewalls
Intrusion Prevention Systems
Network access-control products
Cross-network data-transfer products
Wireless intrusion-prevention systems
Database access-control products
Security-management products
Cryptographic products
Other ICT products providing security functions
However, different product categories may be subject to different requirements, such as Common Criteria certification, security-function confirmation, or national security requirements.
The NIS publishes national security requirements and protection profiles for various security products, including database access control, wireless intrusion prevention, Internet-telephone firewalls, and intrusion prevention systems.
4. Security Conformity Verification vs. Common Criteria Certification
These two concepts should not be treated as identical.
Common Criteria (CC) certification is an evaluation and certification scheme for security functions under defined evaluation criteria.
Security Conformity Verification, on the other hand, is concerned with confirming the safety of a security-enabled ICT product before it is actually introduced and operated by a government or public organization.
Therefore, the statement:
“This product has CC certification.”
should not automatically be interpreted as:
“All government security requirements for our deployment have been satisfied.”
The organization should also check:
Certification scope
Product model
Hardware configuration
Software or firmware version
Security functions included in the certification scope
Actual deployment environment
The NIS separately provides information on security-function testing and national security requirements.
5. Overall Verification Process
A practical process can be summarized as:
Identify product and security functions
↓
Determine whether verification is required
↓
Review security requirements
↓
Prepare application documents
↓
Submit verification application
↓
Document review
↓
Security-function and safety testing
↓
Verification result
↓
Remediation
↓
Actual deployment
↓
Continuous vulnerability and configuration management
This is why verification should be considered from the beginning of the project rather than immediately before completion.
6. Documentation Is Critical
Article 33 requires the submission of documents specified in Appendix 3, and additional documents may be requested when necessary.
The attached guideline's Appendix 3 includes documents such as:
Security Conformity Verification application
ICT product introduction status
Copy of the technical RFP
Security-function checklist
Operational inspection information
CC certificate or security-function confirmation, where applicable
Vendor security-function implementation specification
Security-function operation manual
Basic and detailed design documents
Development completion report
The required documents can differ depending on whether the product is commercial or developed specifically for the organization.
Therefore, project managers should create a verification-document checklist at the beginning of the project.
7. What Should Be Included in the RFP?
A common project-management mistake is to address security conformity only after the product has already been selected.
The RFP should clearly define requirements concerning:
Product information
Product name
Manufacturer
Model
Software version
Firmware version
Major security functions
Security functions
Access control
Authentication
Encryption
Audit logging
Administrator privilege management
Security-policy management
Security-log management
Intrusion detection and prevention
Verification support
Required verification documentation
Security-function specifications
Operation manuals
Design documentation
Testing support
Vulnerability remediation
Technical support
This makes it much easier to hold vendors accountable for supplying the information required for verification.
8. What Happens During Safety Testing?
Article 34 provides that the NIS reviews the submitted documents and may test the safety of the product, including whether its security functions operate properly. Additional information may be requested when necessary. The guideline specifies that requested information must generally be submitted within 10 business days.
The NIS may also commission relevant testing activities to the National Security Research Institute.
If testing cannot proceed because the product or required information has not been provided, the verification procedure may be suspended or the test application cancelled.
Therefore, project managers should prepare:
Test products
Test environment
Administrator and test accounts
Network configuration
Product configuration
Technical documentation
Vendor technical support
before the actual testing begins.
9. Verification Does Not End With the Test Result
Receiving a verification result does not necessarily mean the project is finished.
Under Article 35, the organization must implement the required measures based on the verification result and report the outcome.
A useful management table is:
Item | Management Information |
|---|---|
Verification result | Official result |
Vulnerability | Identified issue |
Remediation | Patch/configuration change |
Responsible person | Person in charge |
Completion date | Actual remediation date |
Evidence | Test/log/screenshots |
Status | Completed / pending |
This converts the verification result into an actual security-management process.
10. Verification Does Not Mean Permanent Security
Security verification should never be interpreted as a permanent guarantee that a product will always be secure.
Article 36 addresses newly discovered vulnerabilities in products that have already completed verification. Organizations are required to remove or remediate such vulnerabilities and report the relevant results.
Organizations should therefore continuously monitor:
Vendor security advisories
Vulnerability information
Security patches
Firmware updates
Administrator accounts
Security logs
Security configuration
New vulnerabilities
Security verification should be connected to the organization's operational security-management process.
11. What If the Product Configuration Changes?
Products often change after deployment.
Examples include:
Software upgrades
Firmware upgrades
Security-module changes
Network architecture changes
Addition of components
Integration with another system
Changes to security functions
Use for a different purpose
Article 37 states that when the security-related configuration of a verified product changes, or when it is operated for a purpose different from the original deployment purpose, the organization should consult the NIS and take necessary measures, including re-verification where required.
Therefore, configuration management and change management should be part of the security process.
12. Re-Verification
Appendix 3 distinguishes between documents required for initial verification and re-verification.
For re-verification, documents may include:
Verification application
ICT product introduction status
Security-function checklist
Operational inspection information
Change-analysis documentation
A practical change-management process is:
Change identified
→ Record the change
→ Analyze security impact
→ Compare with previous verification scope
→ Security review
→ Consult the NIS if necessary
→ Perform re-verification or other required measures
→ Test
→ Deploy
13. Common Mistakes in Government IT Projects
Mistake 1: Assuming CC certification is automatically sufficient
Certification scope, product model, version, and actual security functions must also be reviewed.
Mistake 2: Starting verification just before project completion
Insufficient documentation or an unavailable test environment can delay the project.
Mistake 3: Assuming the vendor will handle everything
The organization still needs to manage the verification process and required documentation.
Mistake 4: Failing to match the actual product model
Manufacturer, product name, model, version, firmware, and certification information should be accurately managed.
Mistake 5: Ignoring post-verification changes
New vulnerabilities and configuration changes can occur after verification.
14. Practical Checklist for Project Managers
Planning
Identify security functions
Determine whether verification applies
Check national security requirements
Check applicable certification or confirmation schemes
Procurement
Include security requirements in the RFP
Specify required verification documents
Define vendor responsibilities
Define vulnerability-remediation responsibilities
Implementation
Confirm actual product model
Confirm software/firmware version
Confirm certification/verification scope
Obtain security-function specifications
Obtain operation manuals
Prepare testing environment
Verification
Prepare all required documents
Prepare for additional information requests
Provide the test product
Assign vendor technical support
Operations
Complete remediation measures
Monitor vulnerabilities
Manage patches and versions
Manage configuration changes
Review changes in operational purpose
Consider re-verification when necessary
15. The Key Point: Verification Should Not Be Treated as the Final Administrative Gate
Treating Security Conformity Verification as a final administrative procedure can create serious project-management problems.
If the organization purchases the product first and only later discovers that required documents, testing environments, or technical information are missing, project schedules can be delayed.
A better approach is:
Planning
→ Security requirements
→ RFP
→ Contract
→ Product selection
→ Test environment
→ Verification documentation
→ Verification
→ Remediation
→ Operation
This makes security conformity part of the entire information-system lifecycle.
16. Key Points for 2026
The attached guideline incorporates amendments effective May 1, 2026.
The amendments include changes related to the title and application provisions of Article 32, submission requirements under Article 33, and safety testing and additional-information requirements under Article 34.
For this reason, organizations should avoid relying solely on old manuals or blog posts. The latest version of the National Cybersecurity Basic Guidelines and current NIS notices and requirements should be checked before starting an actual verification process.
The NIS provides official information on verification notices, security requirements, and security-function testing. It has also published materials such as guidance for preparing security-function implementation specifications.
Conclusion
Security Conformity Verification can be summarized as follows:
It is a security-management process for confirming the safety of ICT products with security functions before deployment and for continuing to manage vulnerabilities and changes after deployment.
For government and public-sector information-system managers, six principles are particularly important:
Identify whether verification applies early in the project.
Include security and documentation requirements in the RFP and contract.
Check the actual product model, version, and security-function scope—not just the existence of a certificate.
Prepare verification documents well before the project reaches completion.
Complete all remediation measures identified through verification.
Continue managing vulnerabilities, configuration changes, and changes in operational purpose after verification.
As government information systems increasingly incorporate cloud services, AI, virtualization, external integrations, and complex network architectures, security verification should be viewed not as a one-time administrative task but as part of the entire information-security lifecycle from planning through operation.
For actual projects, the latest NIS requirements, notices, forms, and product-specific requirements should always be checked before proceeding.