The Personal Information & Information Security Management System (ISMS-P) is South Korea's flagship national certification scheme for the governance, protection and continuous management of both information assets and personal data. Administered under the authority of the Korea Internet & Security Agency (KISA), ISMS-P consolidates two historically separate certifications - the Information Security Management System (ISMS) and the Personal Information Management System (PIMS) - into a single, harmonised framework. For any organisation operating a Korean-facing digital service, handling the personal data of Korean residents, or supplying critical information and communications infrastructure, ISMS-P is the definitive benchmark of security and privacy maturity, and in many cases a statutory obligation rather than a voluntary badge.
This guide is written for a dual audience. For the auditor and assessor, it enumerates every control domain and item, the evidence you should expect to inspect, and the certification lifecycle you must navigate. For the CISO, Chief Privacy Officer (CPO) and implementation team, it lays out a phased roadmap, scoping logic, a maturity model, KPIs and the practical gaps that most frequently derail a first-attempt certification. ISMS-P is unusual among global schemes in that it is legally anchored in three interlocking statutes - the Network Act (Act on Promotion of Information and Communications Network Utilisation and Information Protection), the Personal Information Protection Act (PIPA), and their enforcement decrees - which makes it as much a compliance instrument as a security standard.
Copyright and source note
ISMS-P certification criteria, notification texts and KISA guidance are the intellectual property of KISA and the Korea Communications Commission (KCC) / Ministry of Science and ICT (MSIT) / Personal Information Protection Commission (PIPC). This guide is an original, plain-English interpretation prepared by CyberSigma for educational purposes. It does not reproduce the official Korean-language criteria verbatim. Organisations must obtain the authoritative certification criteria (인증기준) and detailed guidance directly from KISA (isms.kisa.or.kr) and rely on an accredited certification body for any binding assessment.
What is ISMS-P?
ISMS-P (정보보호 및 개인정보보호 관리체계 인증) is a management-system certification that evaluates whether an organisation has established, implemented and continuously operates a comprehensive set of administrative, physical and technical safeguards covering both information security and the entire personal-data lifecycle. It was launched in its unified form in 2018, merging the older ISMS scheme (in force since 2002, mandatory since 2013) with the voluntary PIMS/PIPL certifications. The unification was designed to remove duplicated audits, reduce the compliance burden of dual certification and give the market a single trust signal.
The scheme offers two certification tracks. The first, plain ISMS, certifies only the information security management system - roughly 80 of the total control items - and is the track that satisfies the statutory mandatory-certification requirement. The second, ISMS-P, is the fuller certification that additionally covers the personal-information protection management system, adding a dedicated domain of privacy-lifecycle controls. An organisation may choose ISMS-P voluntarily to demonstrate privacy leadership even where only ISMS is legally required. Certification is valid for three years, subject to a mandatory annual maintenance (surveillance) audit in each of the two intervening years, after which a full renewal audit is required.
Governance is layered. The policy owners are the KCC and MSIT (for the information-security limb) and the PIPC (for the personal-information limb). KISA acts as the operating authority and certification-management institution, maintaining the criteria, training and appointing auditors, and running the certification committee. Accredited certification bodies (인증기관) and designated assessment teams conduct the on-site audits, while the certification committee reviews findings and issues the certificate.
Who must comply / scope of applicability
ISMS certification is mandatory for defined categories of information and communications service providers (ICSPs) and certain other operators. The obligation is triggered by revenue and user-scale thresholds set out in the Network Act enforcement decree, and by sector. Organisations below the thresholds may still certify voluntarily - and increasingly do so because Korean enterprise and public buyers treat the certificate as a procurement prerequisite. The table below summarises the principal mandatory categories.
| Category of obligated operator | Threshold / trigger | Notes |
|---|
| Telecommunications business operators (ISPs / carriers) | Providers of dedicated internet-line connection services nationwide | Mandatory regardless of size for licensed telecom carriers |
| Internet Data Centres (IDC / hosting / co-location) | Operating a commercial data-centre service | Includes cloud infrastructure providers hosting third-party services |
| Information and communications service providers by revenue | Prior-year ICS revenue of KRW 100 billion or more | Large platform, portal and e-commerce operators typically captured here |
| Information and communications service providers by users | Daily-average users of 1 million or more over the preceding three months | Measured across the service; high-traffic apps and portals |
| Hospitals (upper-tier general hospitals) | Designated tertiary / upper general hospitals | Sector-specific mandate reflecting sensitive health data |
| Universities / higher-education institutions | Enrolment of 10,000 students or more | Sector-specific mandate |
| Voluntary applicants | Any organisation seeking the trust mark | ISMS or ISMS-P; common for SaaS, fintech and public bodies |
- Scope is defined by the certified service(s), not the whole legal entity - an organisation certifies a named service, its supporting systems and the sites, staff and third parties that operate it.
- Where personal data is processed, the ISMS-P (privacy-inclusive) track is strongly advisable and is expected by the PIPC as evidence of PIPA due diligence.
- Foreign-domiciled operators serving Korean users at the mandatory thresholds are not exempt; scope and enforcement extend to cross-border services targeting Korean residents.
- Non-compliance with a mandatory certification obligation exposes the operator to administrative fines and corrective orders under the Network Act.
Structure of ISMS-P
The ISMS-P certification criteria are organised into three top-level areas, subdivided into domains and then into individual certification items (인증기준 항목). The first two areas - management-system operation and protection-measure requirements - together form the ISMS scope. The third area adds the personal-information lifecycle requirements that elevate ISMS to ISMS-P. In total the framework comprises 102 certification items: 80 for the ISMS scope and a further 22 for the personal-information protection scope.
| Area | Domain | Approx. items | Applies to |
|---|
| 1. Management system establishment & operation | 1.1 Management system foundation | 7 | ISMS & ISMS-P |
| 1. Management system establishment & operation | 1.2 Risk management | 4 | ISMS & ISMS-P |
| 1. Management system establishment & operation | 1.3 Management-system operation | 3 | ISMS & ISMS-P |
| 1. Management system establishment & operation | 1.4 Management-system inspection & improvement | 3 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.1 Policy, personnel & asset management | 3 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.2 Human-resource security | 6 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.3 External-party security | 4 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.4 Physical security | 7 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.5 Authentication & authorisation management | 6 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.6 Access control | 7 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.7 Cryptography applications | 2 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.8 Secure development lifecycle | 6 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.9 System & service operation management | 7 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.10 System & service security management | 9 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.11 Incident prevention & response | 5 | ISMS & ISMS-P |
| 2. Protection-measure requirements | 2.12 Disaster recovery & business continuity | 2 | ISMS & ISMS-P |
| 3. Personal-information processing requirements | 3.1 Protection at collection | 7 | ISMS-P only |
| 3. Personal-information processing requirements | 3.2 Protection at retention & use | 5 | ISMS-P only |
| 3. Personal-information processing requirements | 3.3 Protection at provision (to third parties) | 4 | ISMS-P only |
| 3. Personal-information processing requirements | 3.4 Protection at destruction | 2 | ISMS-P only |
| 3. Personal-information processing requirements | 3.5 Data-subject rights protection | 4 | ISMS-P only |
Area 1 (management system) is deliberately styled as a Plan-Do-Check-Act cycle, mirroring the discipline familiar from ISO/IEC 27001. Area 2 is the large body of operational safeguards. Area 3 tracks the personal-data lifecycle from collection through to destruction and the exercise of data-subject rights. Every certified organisation is assessed against all applicable items; there is no 'statement of applicability' style exclusion as generous as ISO's - an item may be deemed not-applicable only where the underlying activity genuinely does not occur, and this must be justified to the assessor.
Master assessment checklist
This is the operative heart of the guide. Each subsection below corresponds to a domain of the certification criteria. For every domain we set out, item by item, what an assessor must verify and the typical evidence that demonstrates conformity. Implementers should treat each 'What to verify' cell as a control objective to be met and each 'Typical evidence' cell as the artefact set to be prepared before the audit. No control area is omitted.
Domain 1.1 - Management-system foundation
| What to verify | Typical evidence |
|---|
| Top management has defined and documented the scope of the management system covering the named service(s), assets and locations | Approved scope statement, asset inventory, network and system boundary diagrams |
| An information-security and privacy policy is formally established, approved and communicated | Signed policy set, board/CEO approval minutes, intranet publication records |
| A CISO and (where required) a CPO are appointed with defined qualifications and reporting lines | Appointment letters, KISA/PIPC officer-registration filings, job descriptions, org chart |
| Adequate budget, personnel and resources are allocated to the management system | Annual security budget, headcount plan, resource-allocation minutes |
| Roles and responsibilities for security and privacy are assigned across the organisation | RACI matrix, committee charters, individual responsibility statements |
| A governance/steering committee meets and directs the programme | Committee terms of reference, meeting minutes, decision logs |
| Legal and regulatory requirements applicable to the service are identified and tracked | Legal register mapping Network Act / PIPA / sector rules to controls |
Domain 1.2 - Risk management
| What to verify | Typical evidence |
|---|
| Information assets and personal-data flows are identified, classified and valued | Asset register, data-flow maps, classification scheme, PII inventory |
| A documented risk-assessment methodology is defined and applied at least annually | Risk methodology document, annual risk-assessment schedule |
| Risks are analysed, evaluated against acceptance criteria and prioritised | Risk register with likelihood/impact scoring, risk-acceptance thresholds |
| A risk-treatment plan (protection plan) is produced, approved and resourced | Risk-treatment/protection plan, management approval, budget linkage |
Domain 1.3 - Management-system operation
| What to verify | Typical evidence |
|---|
| The protection plan is implemented and tracked to completion | Implementation tracker, remediation tickets, status dashboards |
| Security and privacy operations are performed per documented procedures | Standard operating procedures, operational logs, run books |
| Management-system activities are documented and records retained | Records index, retention register, controlled-document repository |
Domain 1.4 - Management-system inspection & improvement
| What to verify | Typical evidence |
|---|
| Legal-compliance status is reviewed periodically and gaps addressed | Compliance-review reports, corrective-action logs |
| Internal audits / management-system reviews are conducted at least annually | Internal-audit plan, audit reports, auditor independence evidence |
| Findings drive corrective and preventive action with verified closure | CAPA register, root-cause analyses, closure verification records |
Domain 2.1 - Policy, personnel & asset management
| What to verify | Typical evidence |
|---|
| A hierarchy of policies, standards and procedures is maintained and version-controlled | Document hierarchy map, revision history, approval records |
| Roles for policy owners and asset custodians are assigned and understood | Ownership matrix, custodian assignments |
| Assets are inventoried, owned and classified with handling rules | Asset register with owners, classification/handling guidance |
Domain 2.2 - Human-resource security
| What to verify | Typical evidence |
|---|
| Security roles and responsibilities are defined in job descriptions | JDs, employment terms referencing security duties |
| Pre-employment screening is performed proportionate to role sensitivity | Background-check records, reference checks (PIPA-compliant) |
| Confidentiality / NDA agreements are signed by staff and contractors | Signed NDAs, acknowledgement registers |
| Security-awareness training and role-based training are delivered and measured | Training calendar, attendance records, completion rates, quiz scores |
| A disciplinary process handles security violations consistently | Disciplinary policy, sanction records (anonymised) |
| Joiner-mover-leaver processes revoke access and recover assets on exit | Offboarding checklists, access-revocation logs, asset-return records |
Domain 2.3 - External-party security
| What to verify | Typical evidence |
|---|
| Third-party and subcontractor risks are identified before engagement | Vendor risk assessments, due-diligence questionnaires |
| Security and personal-data-processing obligations are contractually imposed | Contracts with security clauses, PIPA outsourcing (위탁) agreements |
| Outsourced processing of personal data is disclosed and supervised | Consignment disclosure notices, supervision/audit reports of processors |
| Third-party performance and compliance are monitored throughout the term | Vendor scorecards, periodic review minutes, audit findings |
Domain 2.4 - Physical security
| What to verify | Typical evidence |
|---|
| Protected areas (server rooms, IDCs) are defined with layered perimeters | Facility zoning plans, secure-area designation records |
| Physical entry controls restrict and log access to protected areas | Access-card logs, biometric records, visitor logs |
| Environmental controls protect against fire, power and climate hazards | UPS/generator records, HVAC logs, fire-suppression certificates |
| Equipment is sited, maintained and protected against tampering | Maintenance logs, tamper-evidence, equipment siting records |
| Cabling and utilities are protected from interception and damage | Cable-management records, segregation diagrams |
| Media and documents are stored, transported and disposed securely | Media handling procedure, secure-disposal certificates |
| Clear-desk / clear-screen and off-site working controls are enforced | Clear-desk policy, spot-check records, remote-working rules |
Domain 2.5 - Authentication & authorisation management
| What to verify | Typical evidence |
|---|
| User accounts are provisioned through an authorised request-and-approval process | Account-request forms, approval workflow records |
| Authentication mechanisms enforce strong credentials and MFA where warranted | Password policy, MFA configuration, authentication logs |
| Privileged / administrator accounts are minimised, justified and controlled | Privileged-account inventory, approval records, PAM logs |
| Access rights follow least-privilege and need-to-know | Role-permission matrix, authorisation baselines |
| User access rights are reviewed and recertified periodically | Access-review reports, recertification sign-offs |
| Authentication and authorisation events are logged and retained | Auth logs, retention configuration, log-integrity controls |
Domain 2.6 - Access control
| What to verify | Typical evidence |
|---|
| A network access-control policy segments and restricts connectivity | Network diagrams, firewall rulebase, segmentation evidence |
| Application and data access is restricted by authenticated authorisation | Application ACLs, database-access controls |
| Access to personal-data stores is tightly restricted and monitored | PII-access controls, access logs, alerting on anomalous access |
| Remote access is authenticated, encrypted and logged | VPN configuration, remote-access logs, MFA evidence |
| Wireless and mobile access is controlled and secured | Wi-Fi security config, MDM enrolment records |
| Internet and external-service access is filtered and monitored | Proxy/URL-filtering config, egress-monitoring logs |
| Session management enforces timeouts, lockouts and concurrent-session limits | Session-configuration screenshots, lockout policy |
Domain 2.7 - Cryptography applications
| What to verify | Typical evidence |
|---|
| A cryptography policy specifies approved algorithms and applies to data at rest and in transit | Crypto policy, algorithm standard (e.g. use of approved ciphers), TLS config |
| Cryptographic keys are generated, distributed, stored, rotated and destroyed securely | Key-management procedure, KMS/HSM records, rotation logs |
Domain 2.8 - Secure development lifecycle
| What to verify | Typical evidence |
|---|
| Security requirements are defined at analysis and design stages | Requirements docs, threat models, secure-design reviews |
| Secure-coding standards are applied during development | Coding standards, code-review records, SAST results |
| Test and production environments are separated | Environment topology, separation controls |
| Test data does not expose real personal data without safeguards | Data-masking evidence, test-data policy |
| Security testing (vulnerability / penetration) is performed before release | VAPT reports, DAST results, remediation evidence |
| Change and release management controls promotion to production | Change-management records, release approvals, rollback plans |
Domain 2.9 - System & service operation management
| What to verify | Typical evidence |
|---|
| Change management governs all production changes | Change tickets, CAB minutes, emergency-change records |
| System configuration and hardening baselines are defined and enforced | Hardening standards, configuration-compliance scans |
| Patch management applies security updates within defined SLAs | Patch policy, patch-deployment reports, exception register |
| Capacity and performance are monitored to sustain availability | Capacity-monitoring dashboards, threshold alerts |
| Backups are taken, protected and tested for restorability | Backup schedules, restore-test records, offsite storage |
| Logs are generated, protected against tampering and retained | Logging standard, log-integrity controls, retention config |
| Time synchronisation is enforced across systems for reliable logs | NTP configuration, time-sync verification |
Domain 2.10 - System & service security management
| What to verify | Typical evidence |
|---|
| Security systems (firewall, IPS/IDS, WAF) are deployed and tuned | Security-appliance inventory, rule/signature update records |
| Malware protection is deployed, updated and monitored | Anti-malware config, update logs, detection reports |
| Vulnerability management scans, prioritises and remediates weaknesses | Scan schedules, vulnerability reports, remediation SLAs |
| Server and endpoint security baselines are enforced | Endpoint-security config, compliance dashboards |
| Web and application-layer protections guard public services | WAF policy, bot/DDoS mitigation evidence |
| Database security controls protect stored data | DB-security config, audit logging, encryption-at-rest evidence |
| Personal-data displays are masked and printouts controlled | Masking rules for resident-registration numbers and PII on screens/printouts |
| Email and messaging security prevents leakage and phishing | Email-security config, DLP rules, anti-phishing controls |
| Cloud and virtualisation environments are securely configured | Cloud-security posture reports, IAM and network-config evidence |
Domain 2.11 - Incident prevention & response
| What to verify | Typical evidence |
|---|
| Threat and vulnerability intelligence is collected and acted upon | Threat-intel feeds, advisory-handling records |
| An incident-response plan defines roles, severities and escalation | IR plan, contact tree, severity matrix |
| Security monitoring detects and triages events around the clock where required | SOC/SIEM configuration, alert-handling logs |
| Incidents are investigated, contained, eradicated and recovered with records | Incident tickets, forensic notes, post-incident reviews |
| Statutory breach notification to KISA/PIPC and affected data subjects is performed on time | Breach-notification records, regulator filings, notice templates |
Domain 2.12 - Disaster recovery & business continuity
| What to verify | Typical evidence |
|---|
| A BCP/DR strategy defines RTO/RPO for critical services | BCP/DR plan, business-impact analysis, RTO/RPO targets |
| DR arrangements are tested periodically and improvements captured | DR-test reports, failover evidence, lessons-learned log |
Domain 3.1 - Personal information: protection at collection
| What to verify | Typical evidence |
|---|
| Lawful basis and valid consent are obtained before collecting personal data | Consent forms, consent-capture logs, lawful-basis records |
| Collection is limited to the minimum necessary for the stated purpose | Data-minimisation review, field-level justification |
| Sensitive data and unique identifiers (e.g. resident registration numbers) are collected only where legally permitted | Legal-basis documentation, RRN-handling justification and encryption |
| Consent for under-14s is obtained from a legal guardian | Guardian-consent workflow, age-verification records |
| A privacy notice discloses purposes, retention, third parties and rights | Published privacy policy, notice version history |
| Collection through automated means (cookies, trackers) is disclosed and consented | Cookie/consent banner, tracker inventory |
| Personal data collected via outsourced channels is governed contractually | Consignment agreements, collection-channel controls |
Domain 3.2 - Personal information: protection at retention & use
| What to verify | Typical evidence |
|---|
| Personal data is used only for the purposes for which it was collected | Purpose-limitation controls, use-audit records |
| Retention periods are defined and enforced per legal requirements | Retention schedule, expiry-automation evidence |
| Access to stored personal data is restricted, logged and monitored | Access-control matrix, PII-access logs, anomaly alerts |
| Personal data at rest is encrypted, especially unique identifiers | Encryption-at-rest config, RRN/credentials encryption evidence |
| Records of processing activities are maintained and kept current | Processing register, data-inventory updates |
Domain 3.3 - Personal information: protection at provision
| What to verify | Typical evidence |
|---|
| Third-party provision occurs only with consent or lawful basis and is disclosed | Third-party-provision consent, disclosure records |
| Outsourced processing (consignment) is contracted and supervised per PIPA | Consignment contracts, processor-supervision reports |
| Cross-border transfers meet PIPA transfer conditions and are disclosed | Transfer-consent records, cross-border disclosure, safeguards |
| Provision is logged so that recipients and purposes are traceable | Provision logs, recipient register |
Domain 3.4 - Personal information: protection at destruction
| What to verify | Typical evidence |
|---|
| Personal data is destroyed without delay once purpose or retention period ends | Destruction schedule, expiry-triggered deletion logs |
| Destruction uses irrecoverable methods and is evidenced | Destruction procedure, wiping/shredding certificates, deletion logs |
Domain 3.5 - Data-subject rights protection
| What to verify | Typical evidence |
|---|
| Data subjects can access, correct, delete and suspend processing of their data | Rights-request procedure, request-handling logs, response SLAs |
| A designated channel and personal-information manager handle enquiries and complaints | CPO/contact details published, complaint register |
| Automated-decision and profiling rights are addressed where applicable | Profiling notices, opt-out mechanisms |
| Data-subject requests are fulfilled within statutory timeframes | Request-tracking system, timeliness metrics |
Scoping and materiality / tiering
Scoping is the single most consequential decision in an ISMS-P project, because it determines audit effort, cost and the boundary of the trust claim. Unlike a whole-of-entity certification, ISMS-P certifies a named service and everything materially involved in delivering and protecting it.
- Service-based scope: identify each information and communications service in mandatory scope by revenue/user thresholds, then draw the boundary around the systems, networks, facilities, staff and third parties that support it.
- Materiality of assets: any asset that stores, processes or transmits in-scope service data or personal data is material and must be inside the boundary; supporting management systems (identity, logging, backup) are pulled in by dependency.
- Personal-data materiality: the presence of any personal data - and especially sensitive data or unique identifiers such as the resident registration number - elevates scope to the ISMS-P track and triggers Area 3 in full.
- Third-party and cloud inclusion: outsourced processing, IDC/cloud hosting and consignees are in scope; the certified organisation remains accountable and must evidence supervision even where operations are delegated.
- Exclusions: a control item may be marked not-applicable only where the underlying activity genuinely does not occur (e.g. no wireless network), and the justification must satisfy the assessor - broad exclusions are not permitted.
Implementation approach
A first-time ISMS-P certification for a mid-size service provider typically runs six to twelve months. The following phased approach sequences the work so that documentation, technical remediation and operational evidence mature together before the certification audit window.
Phase 1 - Initiation and gap assessment (weeks 1-6)
- Activities: secure executive sponsorship; appoint CISO and CPO; define preliminary scope and thresholds; conduct a gap assessment against all 102 (or 80 for ISMS) certification items; build the asset and personal-data inventories.
- Deliverables: scope statement, appointment filings, gap-assessment report, asset register, PII data-flow maps, high-level remediation roadmap and budget.
Phase 2 - Risk assessment and management-system design (weeks 5-12)
- Activities: define the risk methodology; perform the formal risk assessment; draft the policy/standard/procedure hierarchy; design the governance committee and RACI.
- Deliverables: risk methodology, risk register, risk-treatment (protection) plan, approved policy set, governance charter.
Phase 3 - Control implementation and remediation (weeks 10-24)
- Activities: implement technical safeguards (access control, encryption, logging, network segmentation, hardening); remediate vulnerabilities from VAPT; deploy privacy-lifecycle controls (consent, masking, retention automation, destruction); operationalise vendor management.
- Deliverables: hardened configurations, encryption and key-management, SIEM/monitoring, consent and masking mechanisms, retention/destruction automation, remediated VAPT report.
Phase 4 - Operation and evidence generation (weeks 20-32)
- Activities: run the management system live for a sufficient period to generate operational records; deliver awareness training; execute access reviews, backup/DR tests and incident drills.
- Deliverables: training records, access-review reports, DR-test evidence, incident-drill reports, operating logs demonstrating the system is 'in operation'.
Phase 5 - Internal audit and management review (weeks 30-36)
- Activities: conduct an independent internal audit against every applicable item; hold a management review; close corrective actions.
- Deliverables: internal-audit report, CAPA closure evidence, management-review minutes, readiness declaration.
Phase 6 - Certification audit and maintenance (weeks 34-44 and ongoing)
- Activities: apply to an accredited certification body; undergo documentation review then on-site assessment; remediate any non-conformities; obtain certification-committee decision; then sustain the system and undergo annual surveillance audits.
- Deliverables: certification application, audit findings and responses, ISMS-P certificate (3-year validity), annual maintenance-audit plan.
Maturity / capability model
ISMS-P certification is fundamentally pass/fail against the criteria - an item is either satisfied or a non-conformity. However, CyberSigma applies an internal capability model so that clients can benchmark readiness and prioritise investment before facing the binary certification decision. The model below maps common maturity states to certification outcomes.
| Level | Capability state | Typical characteristics | Certification implication |
|---|
| Level 1 - Initial | Ad hoc | Controls exist informally; documentation sparse; no formal risk assessment | Multiple major non-conformities; not certifiable |
| Level 2 - Developing | Documented | Policies drafted; scope defined; gaps identified but remediation incomplete | Significant minor non-conformities; requires remediation before audit |
| Level 3 - Defined | Implemented | All applicable controls implemented; risk-treatment plan executed | Certifiable with limited minor findings |
| Level 4 - Managed | Operated & measured | Controls operating with records; internal audit and management review complete | Certification-ready; strong evidence base |
| Level 5 - Optimising | Continuously improved | Metrics-driven improvement; automation; mature incident and privacy operations | Certification with minimal findings; sustainable across renewals |
Assessment and audit approach
- Selection and application: choose an accredited certification body, agree scope and the ISMS vs ISMS-P track, and submit the certification application to KISA/the body.
- Documentation (desk) review: the assessment team reviews policies, the risk assessment, the protection plan and management-system records to confirm design adequacy before attending site.
- Audit planning: agree the on-site schedule, sampling approach, sites to visit and interviewees; the team size and days scale with scope and item count.
- On-site assessment: assessors test each applicable certification item through interviews, configuration inspection, log and record sampling, and walk-throughs of physical and technical controls.
- Findings classification: deficiencies are recorded as major or minor non-conformities; majors block certification until resolved, minors require a corrective-action plan.
- Corrective action: the organisation submits evidence closing non-conformities within the permitted window; assessors verify closure.
- Certification-committee deliberation: KISA's certification committee reviews the audit result and the closure evidence and decides whether to grant certification.
- Issuance: the ISMS or ISMS-P certificate is issued with three-year validity and recorded in the public register.
- Surveillance (maintenance) audits: a lighter audit is conducted in each of years one and two to confirm the system remains in operation.
- Renewal: before expiry a full renewal assessment repeats the certification cycle to extend validity for a further three years.
Evidence request list
- Governance: scope statement, security/privacy policies, CISO/CPO appointment filings, committee charters and minutes, legal/compliance register.
- Risk: risk methodology, asset and PII inventories, data-flow maps, risk register, risk-treatment/protection plan with approvals.
- Human resources: job descriptions, screening records, signed NDAs, training calendar and completion records, disciplinary policy.
- Third parties: vendor risk assessments, contracts with security clauses, consignment (outsourcing) agreements, processor-supervision reports.
- Physical: facility zoning, access logs, environmental-control records, media-handling and secure-disposal certificates.
- Identity and access: account-request/approval workflow, MFA and password configuration, privileged-account inventory, access-review reports.
- Network and systems: network and firewall diagrams, hardening baselines, patch reports, backup schedules and restore-test evidence, logging and NTP configuration.
- Security operations: security-appliance inventory, anti-malware and vulnerability-scan reports, VAPT results and remediation, SIEM/monitoring evidence.
- Cryptography: cryptography policy, key-management procedure, encryption-at-rest and TLS configuration.
- Development: secure-coding standards, code-review and SAST/DAST results, change and release records, environment-separation evidence.
- Incident and continuity: IR plan, incident tickets and post-incident reviews, breach-notification records, BCP/DR plan and test reports.
- Personal-data lifecycle: consent records, privacy notices, retention and destruction schedules and logs, third-party-provision and cross-border records, data-subject-rights request logs.
- Assurance: internal-audit reports, CAPA register, management-review minutes.
Roles and responsibilities
| Role | Primary responsibilities |
|---|
| Chief Executive / Top management | Approves scope and policy, allocates budget, owns accountability for certification and statutory compliance |
| Chief Information Security Officer (CISO) | Leads the information-security management system, risk treatment, security operations and audit readiness; a statutory appointment for obligated ICSPs |
| Chief Privacy Officer (CPO) | Owns the personal-information management system, PIPA compliance, consent, data-subject rights and breach notification; a statutory appointment where personal data is processed |
| Security / privacy steering committee | Directs the programme, approves the protection plan and reviews performance |
| IT and system operations | Implement and operate technical controls - access, patching, backup, hardening, monitoring |
| Application / development teams | Embed secure-development and privacy-by-design controls into the service |
| Internal audit | Independently assesses conformity against the certification criteria and reports findings |
| Data owners / custodians | Classify, protect and manage the lifecycle of assets and personal data in their domain |
| All personnel and contractors | Comply with policies, complete training and report security and privacy incidents |
KPIs / metrics to track
- Percentage of applicable certification items assessed as conformant (readiness score).
- Number and severity of open non-conformities and mean time to closure.
- Security-awareness training completion rate and phishing-simulation failure rate.
- Vulnerability remediation SLA adherence (critical/high patched within target).
- Percentage of privileged accounts reviewed and recertified on schedule.
- Access-review completion rate and count of orphaned/dormant accounts removed.
- Mean time to detect and mean time to respond for security incidents.
- Breach-notification timeliness against statutory deadlines (regulator and data subject).
- Percentage of personal data encrypted at rest and of unique identifiers protected.
- Data-subject-rights requests fulfilled within statutory timeframe.
- Retention/destruction compliance - volume of data destroyed on schedule versus overdue.
- Backup restore-test success rate and DR RTO/RPO achievement.
- Third-party assessments completed versus active vendors processing in-scope data.
Readiness checklist
- Executive sponsorship secured and CISO/CPO formally appointed and (where required) registered.
- Certification scope and ISMS vs ISMS-P track decided and documented.
- Asset inventory and personal-data flow maps complete and current.
- Formal risk assessment performed and risk-treatment (protection) plan approved and executed.
- Full policy/standard/procedure hierarchy approved, published and version-controlled.
- All applicable technical controls implemented - access, encryption, logging, hardening, segmentation, monitoring.
- Privacy-lifecycle controls live - consent, minimisation, masking, retention, destruction, data-subject rights.
- VAPT completed and critical/high vulnerabilities remediated with evidence.
- Third-party and consignment agreements in place with supervision evidence.
- Awareness training delivered and completion recorded across staff and contractors.
- Access reviews, backup restore tests and incident/DR drills executed with records.
- Breach-notification process defined and mapped to statutory deadlines.
- Internal audit completed against every applicable item and corrective actions closed.
- Management review held and a formal readiness declaration issued.
- Accredited certification body engaged and audit dates confirmed.
Common gaps and findings
- Scope drawn too narrowly, omitting supporting systems, cloud/IDC dependencies or third parties that materially process in-scope data.
- Risk assessment treated as a paperwork exercise disconnected from the actual protection plan and remediation.
- Resident registration numbers and other unique identifiers stored without encryption or collected without a valid legal basis.
- Consent capture that is bundled, pre-ticked or lacks separate consent for sensitive data, third-party provision and cross-border transfer.
- Retention periods undefined or unenforced, so personal data is kept indefinitely instead of destroyed without delay.
- Privileged-access sprawl - excess administrators, shared accounts and no periodic recertification.
- Logging gaps - insufficient coverage, unprotected logs, short retention or no time synchronisation.
- Outsourcing (consignment) not contracted, disclosed or supervised as PIPA requires.
- Patch and vulnerability management lacking defined SLAs and evidence of timely remediation.
- Incident-response and DR plans documented but never tested, so no drill or restore evidence exists.
- Awareness training delivered informally with no attendance or effectiveness records.
- Internal audit performed by staff who lack independence from the controls they assess.
ISMS-P mapped to other frameworks
| ISMS-P area / theme | ISO/IEC 27001 & 27701 | NIST CSF 2.0 | GDPR / PIPA |
|---|
| Management-system foundation (Area 1) | Clauses 4-10 (context, leadership, planning, operation) | Govern (GV) | Accountability; Article 5(2) / PIPA governance duties |
| Risk management (1.2) | Clause 6.1; ISO 27005 | Identify (ID.RA) | Risk-based approach; DPIA equivalents |
| Access & authentication (2.5-2.6) | Annex A 5.15-5.18, 8.2-8.5 | Protect (PR.AA) | Article 32 security of processing |
| Cryptography (2.7) | Annex A 8.24 | Protect (PR.DS) | Article 32; encryption of unique identifiers |
| Secure development (2.8) | Annex A 8.25-8.29 | Protect (PR.PS) | Data protection by design (Art. 25 / PIPA) |
| Incident response & breach notice (2.11) | Annex A 5.24-5.28 | Respond (RS) / Recover (RC) | Articles 33-34 breach notification / PIPA reporting to PIPC & KISA |
| Business continuity (2.12) | Annex A 5.29-5.30 | Recover (RC) | Availability limb of Article 32 |
| Personal-data lifecycle (Area 3) | ISO 27701 PIMS controls | Protect (PR.DS) / Govern | GDPR Articles 5-9, 12-22 / PIPA collection-to-destruction duties |
| Data-subject rights (3.5) | ISO 27701 A.7 / B.8 | Govern (GV.RR) | GDPR Articles 15-22 / PIPA rights provisions |
How CyberSigma helps
CyberSigma runs end-to-end ISMS-P programmes: a gap assessment against all 102 certification items, service-scope definition, formal risk assessment and protection planning, drafting of the full policy hierarchy, hands-on technical remediation (access control, encryption of resident registration numbers, logging, hardening and monitoring), and build-out of the personal-data lifecycle controls from consent to destruction. Our CERT-In empanelled and privacy specialists then run VAPT, internal audit and management review, prepare your evidence pack, and support you through the certification-body assessment and the certification-committee decision - and stay on to shepherd annual surveillance and three-year renewal. Whether you need statutory ISMS or the fuller ISMS-P privacy certification, we get you certified and keep you certified.
