요약
- ISMS-P 인증을 받은 회사가 클라우드를 옮길 때 흔히 갖는 오해가 있습니다 — 인증을 새로 받아야 한다는 것은 사실이 아닙니다. 변경 관리 통제(2.10.1)와 사후 심사 변경 신고로 처리할 수 있습니다.
- 핵심 절차는 12단계입니다. 사전 위험 평가, 변경 신청, 듀얼 운영, 데이터 무결성 검증, KISA 신고, 사후 심사 보완 순으로 진행됩니다.
- 무중단 마이그레이션은 평균 6~9개월이 소요됩니다. 인증 갱신 비용을 80% 절감할 수 있고, 서비스 중단 없이 진행하는 것도 가능합니다.
1. ISMS-P 인증 범위와 클라우드 변경의 관계
ISMS-P 인증서에는 인증 범위가 명시되어 있습니다. 일반적으로 다음 항목이 포함됩니다.
- 인증 대상 서비스명 (예: "쇼핑몰 SaaS A 서비스")
- 인증 대상 시스템 (예: "AWS 서울 리전 인프라")
- 인증 대상 인력 + 위치
클라우드 이전은 "인증 대상 시스템" 의 중대한 변경 에 해당. 변경 관리 통제 + 사후 심사 신고 의무가 발생하지만,새로운 인증을 받을 필요는 없음.
2. 변경 신고 vs 신규 인증 — 의사결정 표
| 변경 유형 | 변경 신고 | 신규 인증 |
|---|---|---|
| 동일 IaaS 내 리전 변경 | ✅ | — |
| AWS → NCP 등 IaaS 변경 | ✅ | — |
| 온프레미스 → 클라우드 | ✅ (단, 사후 심사 강화) | — |
| 인증 서비스 자체 추가 | — | ✅ |
| 인증 받은 법인 합병·분할 | — | ✅ (재인증) |
3. 12단계 마이그레이션 절차
Phase 1 — 사전 준비 (Week 1-4)
- 인증 범위 재확인 — 현 인증서의 범위 + 자산 목록과 이전 대상 매핑.
- 위험 평가 (1.2.4) — 신·구 클라우드의 위험 비교 평가. 새 클라우드의 ISMS / CSAP / SOC 2 인증 현황 확인.
- 변경 관리 (2.10.1) 신청서 — 내부 정보보호 위원회 의결 + 의사록 보관 (사후 심사 시 확인).
Phase 2 — 환경 구축 (Week 5-8)
- 새 클라우드 통제 구현 — IAM · VPC · KMS · 로그 수집 등 ISMS-P 178개 점검 항목 신·구 환경 모두 구현.
- 증적 자동 수집 설정 — K-ISMS 같은 자동화 도구로 신 환경 통제 작동 검증 (수동 점검 4-6주 → 자동 1주).
Phase 3 — 듀얼 운영 (Week 9-16)
- 병행 운영 (Dual Run) — 일부 트래픽을 새 환경으로 분배. 데이터는 양쪽 동기화. 최소 4-8주.
- 데이터 무결성 검증 — 해시 비교 (SHA-256) + row-count + 샘플 비교 (ISMS-P 2.7.4 무결성 통제).
- 침해사고 모의 (2.11.1) — 새 환경에서 인시던트 대응 절차 모의 훈련.
Phase 4 — 컷오버 (Week 17-18)
- 최종 컷오버 — DNS 전환 (TTL 사전에 60s 로 단축).
- 구 환경 데이터 처리 — 안전한 폐기 (PIPA 제21조·ISMS-P 3.2.5). 폐기 증명서 보관.
Phase 5 — 사후 (Week 19-24)
- KISA 변경 신고 — 변경일 기준 30일 이내. 양식: ISMS 인증 변경 신고서. 첨부: 위험 평가 보고서, 변경 관리 의사록, 새 환경 통제 구현 증적.
- 사후 심사 대응 — 매년 사후 심사에서 변경 사항 + 새 환경 통제 작동 점검. 일반 사후 심사보다 1.2배 시간 소요.
4. 클라우드 별 마이그레이션 특성
| From → To | 난이도 | 주요 고려사항 |
|---|---|---|
| 온프레미스 → AWS | ★★★★ | 물리 보안 통제 → 클라우드 책임 공유 모델 매핑 재작성 |
| 온프레미스 → NCP/NHN/KT | ★★★☆ | CSAP 활용 가능 → ISMS-P 통제 70% 자동 매핑 |
| AWS → NCP | ★★★ | IAM·VPC·KMS 매핑 + 데이터 주권 (한국 보관) 강화 |
| AWS → AWS (서울 리전) | ★★ | 리전 변경만 — 통제 매핑 동일, 데이터 이전만 검증 |
| 퍼블릭 → 멀티클라우드 | ★★★★★ | 신·구 환경 모두 정식 인증 범위에 포함 → 통제 두 배 |
5. 주의 사항 — "재인증 트리거" 5가지
다음 경우에는 단순 변경 신고로 끝나지 않고 재인증 또는 추가 심사가 필요할 수 있다:
- 인증 대상 시스템의 핵심 보안 통제 변경 (예: SSO → 자체 인증)
- 처리하는 개인정보의 종류·범위 확대 (일반정보 → 민감정보)
- 국외 데이터 보관 시작 (한국 → AWS 미국 리전 등)
- 외부 위탁 관계 신규 발생 (CSP 변경 시 별도 위탁 신고)
- 인증 대상 인력 50% 이상 교체
6. 실패 패턴 — 흔한 4가지 함정
- 변경 신고 누락 — 30일 기한 초과 시 사후 심사에서 중대 결함. 인증 정지 위험.
- 신·구 환경 통제 비대칭 — 듀얼 운영 중 한쪽 통제만 작동. 침해사고 시 책임 회피 어려움.
- 구 환경 데이터 미폐기 — 컷오버 후 구 클라우드의 백업·로그 데이터를 잊어 PIPA 제21조 위반.
- 운영 인력 교육 부재 — 새 클라우드 운영 미숙으로 접근 권한 오설정 → 침해사고 발생.
7. 비용 분석
| 항목 | 마이그레이션 (변경 신고) | 신규 인증 |
|---|---|---|
| 심사 수수료 | ₩0 (변경 신고는 무료) | ₩2,000-3,000만 |
| 외부 컨설팅 | ₩1,500-3,000만 | ₩5,000만-1억 |
| 내부 인건비 (6개월) | ₩3,000-6,000만 | ₩6,000만-1.2억 |
| 듀얼 운영 인프라 (3개월) | ₩600-1,200만 | — |
| 합계 | ₩5,000-1.0억 | ₩1.3-2.3억 |
8. 자주 묻는 질문
Q. 클라우드 이전 후 ISMS-P 인증서를 새로 받아야 하나요?
대부분의 경우 아니요. 변경 신고 + 다음 사후 심사에서 검토 받으면 됨. 다만 인증 대상 서비스 자체가 바뀌거나, 처리 정보 종류가 확대되거나, 국외 보관이 새로 발생하면 재인증 또는 추가 심사 필요.
Q. 듀얼 운영 기간 중 두 환경 모두 ISMS-P 통제 적용?
예. 트래픽이 1% 라도 향하는 환경은 모두 인증 범위. 듀얼 운영 시간을 단축하기 위해 자동화 도구로 통제 구현 + 검증을 병행하는 것이 비용 효율.
Q. 마이그레이션 후 첫 사후 심사에서 무엇이 점검되나요?
(1) 변경 관리 절차 준수 여부 (의사록 + 위험 평가), (2) 새 환경의 통제 작동 (자동 증적), (3) 구 환경 데이터 안전 폐기 증명, (4) 변경 신고 적시 제출 여부 — 이 4가지가 핵심 점검 항목.