2026 CSAP Simplified Grade Prep Checklist — A Practical Guide for SaaS Providers
If you found this article after hearing that “you cannot even bid on public-institution SaaS without CSAP,” you are in the right place. Today, entering the public cloud market requires CSAP (Cloud Security Certification) first and then an NIS security verification as well.
The first place security and infrastructure owners get stuck is surprisingly simple: “Is our service Standard Grade or Simplified Grade?” Get that wrong and your quotes, timeline, and deliverables all go off track. This article walks through that first decision, then the application process and costs, frequently failed controls, and a copy-paste-ready list of artifacts.
⚠️ Disclaimer: The number of assessment items, costs, and lead times change with the latest KISA and assessment-body (certification body) notices and quotes, so this article gives no figures beyond the durations set in the notice. Always confirm against official KISA CSAP guidance and a consultation with an assessment body.
📌 Reform ahead (announced 2026-04-20): In a joint press release, MSIT and the NIS said public cloud verification, currently split between CSAP and the NIS security verification, will be unified into a single NIS verification system. The National Cloud Computing Security Guideline and related rules are to be revised in the first half of 2026, with full enforcement from the second half of 2027 after a one-year grace period; CSAP certifications obtained before then keep their validity period. The private general-purpose cloud area is planned to be folded into ISMS as a voluntary cloud-service certification. It also says a public–private verification review committee of relevant agencies and experts from industry, academia and research will assess the fairness and validity of verification results, and that the expertise of existing CSAP assessment bodies will be carried into the new system. The release gives no detailed items or grades for the new verification, so the checklist below follows the current CSAP rules.
Standard Grade vs. Simplified Grade: Which applies to our service?
The current Notice on Security Certification of Cloud Computing Services (MSIT Notice No. 2023-4, in force 2023-01-31) sets certification grades of High, Medium and Low by information-protection level, but High and Medium only take effect once separate criteria are prepared (Addenda Art. 1). Until then, applicants can apply under the previous types (IaaS, SaaS Standard, SaaS Simplified, etc.), and an existing SaaS Simplified certification can be recognized as Low grade (Addenda Art. 3). Check KISA's CSAP guidance for whether High/Medium are in effect and which types you can apply for now. This guide uses the split practitioners work with: “non-critical information → Simplified Grade (Low-grade track)” vs. “critical information → Standard Grade.” Most general business SaaS — collaboration tools, scheduling, CRM, and the like — falls under Simplified Grade.
| Category | Simplified Grade | Standard Grade |
|---|---|---|
| Scope | SaaS that processes non-critical information | Systems that process critical information (resident registration numbers, sensitive data, etc.) |
| Number of assessment items | Relatively few (streamlined) | Many items (full control set) |
| Assessment method | Document review + on-site (fewer check items, lighter burden) | Document review + on-site assessment |
| Multi-tenancy isolation | Broader allowance for logical isolation | Stricter isolation requirements |
| Typical services | General business SaaS, non-critical collaboration tools | Administrative information and high-volume personal-data processing services |
| Prep burden | Medium | High |
Decision tip: Start by asking whether a leak of the information your service processes would have only limited impact on citizens or public administration. If so, prepare on the Simplified Grade track — but always confirm the grade the contracting agency (demanding institution) actually requires. If the agency requires Medium and you prepared Low, the certification is useless in the bid.
Certification types and extra criteria for public agencies (per the notice)
| Item | What the notice says | Provision |
|---|---|---|
| Certification types | IaaS, SaaS, PaaS, and services combining two or more of them | Art. 14(1) |
| Assessment method | Document review and on-site assessment carried out together (site visit) | Art. 17(1) |
| Certification criteria | Criteria by type in Annexes 1–3 | Art. 15(1) |
| Serving public agencies | Annex 4 (additional security requirements for public agencies) applied on top of Annexes 1–3 | Art. 15(2) |
| Detailed check items | KISA publishes detailed check items by type and grade on its website | Art. 15(3) |
The notice does not say which type DaaS (virtual desktop) applies under, so confirm with KISA.
Application process roadmap
| Stage | Owner | Notes |
|---|---|---|
| 1. Application and pre-consultation | Provider → assessment body | Consultation stage |
| 2. Contract | Provider and assessment body | Assessment-fee contract signed |
| 3. Assessment prep (writing artifacts) | Provider | Internal staff or consulting |
| 4. Document and (on-site) assessment | Assessment body | Included in assessment fees |
| 5. Remediation | Provider | 30 days from the day after the assessment ends, extendable up to 90 (notice Art. 17(4)) |
| 6. Certification committee review | KISA / certification body | — |
| 7. Certificate issuance | Certification body | — |
Remediation is the only stage with a duration set in the notice. The length and cost of the other stages depend on system scale and assessment scope, so get a quote and schedule from the assessment body early, working back from your target bid date. The certification committee may also request additional remediation after its review (Art. 17(5)).
Frequently flagged controls checklist (copy-paste ready)
Start your internal review by copying this table as-is. These are the controls most often cited when teams prepare for the first time.
| Control area | Pass criteria | Evidence | Check |
|---|---|---|---|
| Account and privilege separation | Least privilege by role, no shared accounts, grant/revoke procedures in operation | Access-privilege register, approval history | ☐ |
| Administrator access control | MFA on the admin console, source-IP restriction, activity logging | MFA configuration screens, access-control policy | ☐ |
| Encryption in transit | TLS 1.2 or higher enforced on all external communications | SSL configuration, scan results | ☐ |
| Encryption at rest | Encryption applied to DB and storage | Encryption settings, list of in-scope assets | ☐ |
| Key management | Keys stored separately, rotated periodically, access controlled | Key-management policy, KMS configuration | ☐ |
| Log retention period | Meets statutory/baseline retention (typically 1 year or more), tamper protection | Log-management register, retention policy | ☐ |
| Physical and logical isolation | Public-sector zone isolation, multi-tenant isolation | System architecture diagram, isolation design | ☐ |
| Backup and recovery | Regular backups, recovery procedures, and recovery tests performed | Backup policy, recovery-test records | ☐ |
| Security patch management | Defined OS/middleware patch cycle and actual execution | Patch-management register, change records | ☐ |
Pre-assessment deliverables list
Assessment is ultimately a process of proving things in writing. The most common delay is operations that work well but have no documents, which then get pushed into remediation. Fill these artifacts in advance.
| Artifact | Purpose | Prep difficulty |
|---|---|---|
| Information security policy and guidelines | Foundational documents for how controls are operated | Medium |
| System architecture diagram | Evidence of infrastructure, network, and isolation design | Medium |
| Asset inventory | Identification of hardware, software, and data | Low |
| Access-privilege register | History of account and privilege grant/revoke | Medium |
| Encryption policy | Stated standards for transit, rest, and key management | Medium |
| Log-management register | Retention period, in-scope logs, and review cycle | Low |
| Change-management records | Traceability of patches and configuration changes | Medium |
| Outsourced CSP evidence | CSAP certificate and contract for the IaaS in use | High |
| Risk analysis report | Threats and vulnerabilities per asset and the basis for chosen safeguards | High |
| Incident-response procedure and drill records | Response structure and evidence that drills were actually run | Medium |
| Vulnerability assessment and remediation history | Assessment results and records of completed patches/fixes | Medium |
Common fail and remediation reasons — avoid these in advance
These remediation findings show up repeatedly in practice. Checking them before you start can save an entire round.
- Log retention too short: Settings such as “we only keep 30 days for operational convenience” are the most common finding. Configure retention to meet the baseline in advance.
- No MFA on admin accounts: MFA is on for end users, but the admin console is still ID/password only. Apply MFA to administrator accounts without exception.
- IaaS CSAP certification not verified: Cases where nobody checked whether the cloud infrastructure (IaaS) the SaaS runs on is itself CSAP-certified. SaaS certification only means something on certified IaaS. Always verify the CSP’s certification scope.
- Misreading physical-isolation requirements: Over-interpreting Simplified Grade as needing Standard Grade–level physical isolation, or claiming logical isolation with no evidence. Map requirements accurately to the grade.
- Policy documents vs. actual operations: The document says “quarterly patches” but there is no patch history — instant remediation. Documents must reflect operations, and operations must follow the documents.
One lesson from the field
Looking at first-time CSAP preparations, teams burn more time on document–operations alignment than on technical controls. TLS, encryption, and MFA are a setting or two. If the cycle written in the policy does not match actual operations logs, remediation rounds repeat and the schedule slips badly. That is why I recommend not starting with artifacts: first record how you actually operate, then align the policy language to that. Write an idealized policy first and operations will never catch up.
Reconciling the Certification Scope with Real Assets
New servers, storage, or admin consoles missing from the scope document, dev/test network boundaries that differ from the document, or data flows to external SaaS (monitoring, log analytics) missing from the architecture diagram all lead to remediation requests. If you manage scope with tags, you can reconcile real assets against the document mechanically.
# e.g. on AWS, if scope is marked with a tag, list all such resources
aws resourcegroupstaggingapi get-resources \
--tag-filters Key=csap-scope,Values=in \
--query 'ResourceTagMappingList[].ResourceARN' --output text | tr '\t' '\n' | sort > cloud_assets.txt
# compare with the scope document's asset list (assume ARN in first CSV column)
cut -d, -f1 scope_assets.csv | sort > doc_assets.txt
comm -3 cloud_assets.txt doc_assets.txtLines printed by comm -3 exist only in the document or only in reality. Some resources may be untagged, so compare once more against a full-account listing.
After Certification: Follow-up and Renewal Assessments
The notice divides assessments into initial, follow-up, and renewal assessments (Art. 2, items 8–10). Certification is not one-and-done, so put the schedule on the calendar early.
| Category | Timing | Preparation points |
|---|---|---|
| Validity period | Period stated on the certificate | Confirm on the certificate and with KISA |
| Follow-up assessment | Every year during the validity period | Accumulate operating evidence continuously; reflect service and scope changes |
| Renewal assessment | Apply at least 6 months before expiry | Full re-check at the level of the initial assessment |
Gaps in evidence between follow-up assessments all surface at renewal. Letting the records in the artifact list above accumulate on their normal cycle is the cheapest approach.
Conclusion: three-step prep priority
- Lock the grade: Confirm Simplified vs. Standard from the demanding institution’s required grade plus the criticality of the information you process.
- Verify the infrastructure prerequisite: Validate the CSAP certification scope of the IaaS you run on, and configure the high-fail items first — MFA, log retention, encryption.
- Align documents and operations: Write the artifacts above against actual operations, and remove mismatches between policy and real history.
Finish these three steps and you are ready to walk into an assessment-body consultation. Copy the tables above into your internal wiki and split the checkboxes across owners.
Frequently asked questions (FAQ)
Q. We are non-critical SaaS — can we always go Simplified Grade? A. Even if the information you process would put you on Simplified Grade, the grade the public institution you sell to requires takes priority. Confirm the required grade in the bid notice or in pre-discussions first.
Q. Does our IaaS (cloud infrastructure) also need its own CSAP? A. The SaaS provider does not need to certify the IaaS itself, but the service must run on CSAP-certified IaaS. Obtain the CSP’s certification scope and certificate as evidence.
Q. What are the exact prep time and cost? A. The only duration set in the notice is remediation (30 days from the day after the assessment ends, up to 90); overall duration and cost vary widely with scale. The only accurate way to lock item counts, fees, and duration is official KISA CSAP guidance plus an assessment-body quote.
Q. If we hold ISMS-P, are we exempt from the CSAP assessment? A. No. ISMS-P covers the overall information security and privacy management system, while CSAP assesses the security of cloud services provided to public agencies; their purposes and legal bases differ. The notice has no provision exempting ISMS-P holders from the CSAP assessment. Where the areas overlap — policies, access control, log management — documents and operating evidence built for ISMS-P can be reused in CSAP preparation, but the Annex 4 requirements for public agencies need separate preparation. Under the 2026-04-20 announcement, the private general-purpose cloud area is to move into ISMS and the public sector to a single NIS verification.
Sources · checked 2026-10-06
- MSIT press release, ·, when (2026-04-20) — single NIS verification system; guideline revision in H1 2026; enforcement from H2 2027 after a one-year grace period; existing CSAP validity recognized; public–private verification review committee; private general-purpose area folded into ISMS
- National Law Information Center, Notice on Security Certification of Cloud Computing Services (MSIT Notice No. 2023-4, in force 2023-01-31) — Art. 14 (types: IaaS, SaaS, PaaS, combined; grades: High, Medium, Low), Art. 15 (criteria in Annexes 1–3, Annex 4 added for public agencies, detailed check items published by KISA), Art. 17(1) (document and on-site assessment together), Art. 17(4) (remediation 30 days, up to 90), Art. 17(5) (additional remediation after committee review), Art. 2 items 8–10 (initial, follow-up, renewal assessments), Art. 20(1) (renewal application 6 months before expiry), Addenda Art. 1 (High/Medium after separate criteria), Addenda Art. 3 (previous types; SaaS Simplified recognized as Low)
The scheme and notice can change, so re-check KISA and MSIT notices before applying.
Sources and checks vary by article. Only articles with a recorded check date, scope and sources below were checked, and only within that scope. For other articles, verify against the current docs for your version before applying anything, and email us about errors. Editorial policy · email us
This article has no recorded human check (date and scope) yet.
Comments
Be the first to comment.