핵심 답변: 침해사고 대응 매뉴얼은 해킹·악성코드·서비스 거부 공격 같은 사고가 났을 때 누가, 언제, 무엇을 할지를 미리 정해 둔 문서입니다. 절차는 보통 아래 단계로 구성하며, 정보통신서비스 제공자는 사고를 알게 된 때부터 24시간 이내에 과학기술정보통신부 또는 한국인터넷진흥원(KISA)에 신고해야 하고, 개인정보 유출이 기준에 해당하면 72시간 이내에 통지·신고해야 합니다.
- 준비: 대응 조직, 연락망, 로그·백업, 매뉴얼을 미리 갖춥니다.
- 탐지와 분석: 이상 징후를 확인하고 사고 여부와 범위를 판단합니다.
- 격리·제거·복구: 피해 확산을 막고 원인을 제거한 뒤 서비스를 되살립니다.
- 신고와 소통: 법정 기한 안에 신고하고 고객·임직원에게 알립니다.
- 사후 활동: 보고서를 쓰고 재발 방지 대책을 매뉴얼에 반영합니다.
최종 업데이트: 2026년 11월
침해사고란 무엇인가요?
침해사고는 해킹, 컴퓨터바이러스, 서비스 거부 공격 등의 방법으로 정보통신망이나 관련 정보시스템을 공격해 발생한 사태를 말합니다.
이 정의는 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」(정보통신망법) 제2조의 용어 정의에서 나옵니다. 실무에서는 랜섬웨어 감염, 계정 탈취, 웹셸 업로드, 클라우드 설정 오류를 통한 데이터 노출, 디도스 공격 등이 모두 침해사고 대응 대상이 됩니다. 개인정보가 함께 빠져나갔다면 개인정보 보호법상 "유출" 대응이 추가로 필요하다는 점이 중요합니다. 하나의 사고에 두 법의 의무가 동시에 걸릴 수 있으므로, 매뉴얼은 처음부터 두 갈래를 함께 다루도록 설계해야 합니다. 정확한 조문은 법제처에서 최신 법령을 확인하세요.
침해사고 대응 절차는 어떤 단계로 구성되나요?
가장 널리 참고되는 기준은 NIST SP 800-61의 4단계 생명주기이며, 국내에서는 7단계 모델도 함께 쓰입니다.
NIST SP 800-61 Rev. 2(2012)는 대응 생명주기를 준비 → 탐지·분석 → 격리·제거·복구 → 사후 활동의 4단계로 설명했습니다. 2025년 4월 발표된 Rev. 3는 Rev. 2를 대체하면서 대응 활동을 NIST CSF 2.0의 6개 기능(Govern, Identify, Protect, Detect, Respond, Recover)에 맞춰 재구성했습니다. 그래도 현장에서 절차서를 쓸 때는 4단계 흐름이 이해하기 쉬워 여전히 뼈대로 많이 쓰입니다. 보다 상세한 플레이북 구성은 AI Incident Response Playbook 구축 가이드에서도 다뤘습니다.
| NIST 4단계 (Rev. 2) | 주요 활동 | 산출물 |
|---|---|---|
| 준비 (Preparation) | 대응팀 구성, 연락망, 로그 수집·보관, 백업, 훈련 | 매뉴얼, 연락처 목록, 자산 목록 |
| 탐지·분석 (Detection & Analysis) | 경보 확인, 오탐 판별, 영향 범위·심각도 판단 | 사고 접수 기록, 초기 분석 메모 |
| 격리·제거·복구 (Containment, Eradication & Recovery) | 네트워크 분리, 계정 차단, 악성 요소 제거, 백업 복원 | 조치 이력, 복구 확인서 |
| 사후 활동 (Post-Incident Activity) | 교훈 회의, 원인 분석, 매뉴얼 개선 | 사고 보고서, 개선 과제 목록 |
침해사고 대응 7단계는 무엇인가요?
국내에서 널리 쓰이는 7단계 모델은 사고 전 준비 → 사고 탐지 → 초기 대응 → 대응 전략 체계화 → 사고 조사 → 보고서 작성 → 해결 순서입니다. IT위키는 이 7단계를 KISA의 「침해사고 분석 절차 안내서」에 정리된 모델로 소개합니다. 다만 저희는 안내서 원문에서 단계 명칭을 직접 대조하지는 못했으므로, 공식 문서로 인용할 때는 KISA 원문을 확인하시기 바랍니다.
| 7단계 | 핵심 질문 | NIST 4단계와의 대응 |
|---|---|---|
| 1. 사고 전 준비 | 누가 대응하고 무엇으로 증거를 남기나? | 준비 |
| 2. 사고 탐지 | 정말 사고인가, 오탐인가? | 탐지·분석 |
| 3. 초기 대응 | 대응팀을 소집하고 기초 정보를 수집했나? | 탐지·분석 |
| 4. 대응 전략 체계화 | 격리할지, 관찰할지, 신고·수사 의뢰할지? | 격리·제거·복구 |
| 5. 사고 조사 | 침입 경로, 피해 범위, 유출 여부는? | 탐지·분석 / 격리·제거·복구 |
| 6. 보고서 작성 | 경영진·기관에 무엇을 보고하나? | 사후 활동 |
| 7. 해결 | 재발 방지 대책이 적용됐나? | 복구 / 사후 활동 |
시험 문제로 자주 나오는 "대응팀을 소집하고 네트워크와 시스템 정보를 수집하는 단계"는 이 모델에서 초기 대응 단계에 해당합니다. 어느 모델을 고르든 조직 규모에 맞게 단계를 합치거나 나눠도 됩니다. 중요한 것은 단계마다 책임자와 산출물이 정해져 있는지입니다.
침해사고 대응 7단계와 NIST SP 800-61 4단계의 대응 관계
침해사고 대응 매뉴얼(절차서)에는 무엇을 넣어야 하나요?
좋은 절차서는 사고 당일 처음 보는 사람도 따라 할 수 있도록 목적, 조직, 단계별 절차, 신고 기준, 연락처, 양식을 한 문서에 담습니다.
아래는 중소·중견 조직이 바로 쓸 수 있는 목차 예시입니다. 분량보다 최신성이 중요하므로 연락처와 담당자는 분기마다 점검하는 것이 좋습니다.
- 목적과 적용 범위: 대상 시스템, 클라우드 계정, 외주·위탁 범위
- 용어 정의: 침해사고, 개인정보 유출, 심각도 등급
- 대응 조직과 역할: 사고대응 책임자, 기술 담당, 법무·개인정보 담당, 홍보
- 심각도 분류 기준: 서비스 중단 여부, 개인정보 포함 여부, 영향 고객 수
- 단계별 대응 절차: 탐지 → 초기 대응 → 격리 → 조사 → 복구 → 사후 활동
- 법정 신고·통지 기준과 기한: 정보통신망법, 개인정보 보호법, 업권별 규정
- 증거 보존 지침: 수집 순서, 보관 위치, 인수인계 기록
- 내·외부 커뮤니케이션: 보고 체계, 고객 공지 템플릿, 언론 대응 창구
- 시나리오별 플레이북: 랜섬웨어, 계정 탈취, 웹 해킹, 클라우드 키 노출, 디도스
- 비상 연락망: 내부 담당자, 호스팅·클라우드 사업자, 보안관제 업체, KISA·수사기관
- 부록 양식: 사고 접수서, 조치 이력표, 신고서 초안, 사후 보고서
- 훈련과 개정 이력: 모의훈련 일정, 개정 날짜와 변경 내용
랜섬웨어 플레이북을 따로 만든다면 랜섬웨어 방어·복구 가이드의 백업·복구 항목을 참고하시고, 클라우드 환경은 클라우드 설정 오류 대응 플레이북을 시나리오로 붙이면 좋습니다.
누가 어떤 역할을 맡아야 하나요?
역할은 RACI(실행·최종책임·협의·통보) 방식으로 한 장에 정리해 두면 사고 당일 혼선이 크게 줄어듭니다.
| 업무 | 사고대응 책임자 | IT·보안 담당 | 개인정보·법무 | 경영진 | 홍보·CS |
|---|---|---|---|---|---|
| 사고 선언·심각도 판단 | A | R | C | I | I |
| 격리·차단 조치 | A | R | I | I | - |
| 증거 보존 | A | R | C | - | - |
| KISA·과기정통부 신고 | A | C | R | I | - |
| 개인정보 유출 통지·신고 | C | C | R/A | I | C |
| 고객·언론 공지 | C | - | C | A | R |
| 복구·재발 방지 | A | R | I | I | - |
R은 실행, A는 최종 책임, C는 사전 협의, I는 결과 통보를 뜻합니다. 보안 전담 인력이 없는 조직은 IT·보안 담당 칸을 외부 보안관제(MDR) 업체와 나눠 맡는 경우가 많습니다. 이때도 신고와 고객 공지 같은 법적 결정은 회사 내부 책임자가 맡아야 합니다.
심각도 등급은 어떻게 나누나요?
심각도는 서비스 영향, 개인정보 포함 여부, 확산 가능성 세 가지 기준으로 3~4단계로 나누는 것이 단순하고 실용적입니다.
등급마다 누구를 깨우고, 언제 경영진에게 보고하고, 어떤 신고 검토를 시작할지를 미리 묶어 두면 판단 시간이 줄어듭니다. 아래 표는 예시이므로 조직의 서비스 특성에 맞게 기준을 조정하세요.
| 등급 | 판단 기준 예시 | 소집 범위 | 신고 검토 |
|---|---|---|---|
| 1등급 (심각) | 핵심 서비스 중단, 랜섬웨어 확산, 개인정보 유출 확인 | 대응팀 전원, 경영진 즉시 보고 | 정보통신망법·개인정보 보호법 신고 즉시 검토 |
| 2등급 (높음) | 서버·계정 침해 확인, 유출 가능성 조사 중 | 대응 책임자, IT·보안, 개인정보 담당 | 침해사고 신고 대상 여부 판단 |
| 3등급 (보통) | 단일 단말 악성코드, 차단된 공격 시도 | IT·보안 담당 | 기록 후 필요 시 상향 |
| 4등급 (낮음) | 오탐, 정책 위반 등 경미한 이벤트 | 담당자 | 해당 없음(기록만) |
사고 발생 후 첫 24시간에는 무엇을 해야 하나요?
첫 24시간의 목표는 피해 확산 차단, 증거 보존, 법정 최초 신고 준비 세 가지입니다.
- 0~1시간: 사고 접수 시각을 기록하고(신고 기한의 기준점이 됩니다), 대응 책임자에게 보고하고, 대응팀을 소집합니다.
- 1~4시간: 감염·침해 의심 시스템을 네트워크에서 분리하되 전원은 바로 끄지 않습니다. 탈취 의심 계정의 비밀번호와 API 키, 세션을 교체·폐기합니다.
- 1~4시간: 메모리, 주요 로그, 클라우드 감사 로그를 먼저 확보합니다. 로그 보관 기간이 짧은 서비스부터 내보냅니다.
- 4~12시간: 영향 범위(시스템, 계정, 데이터)를 파악하고 개인정보 포함 여부를 판단합니다.
- 4~12시간: 백업이 안전한지 확인합니다. 백업 서버까지 접근 가능한 계정이 탈취됐는지 점검합니다.
- 24시간 이내: 정보통신서비스 제공자라면 그때까지 파악된 사항으로 KISA에 최초 신고합니다. 원인이 다 밝혀지지 않았어도 기다리지 않습니다.
- 계속: 모든 조치를 시각·담당자와 함께 조치 이력표에 기록합니다.
탐지가 늦으면 이 시계 자체가 늦게 시작됩니다. 야간·주말 경보를 볼 사람이 없는 조직이라면 중소기업 보안관제 시작 방법에서 내부 인력 없이 탐지 체계를 갖추는 방법을 확인해 보세요.
증거는 어떻게 보존해야 하나요?
증거는 사라지기 쉬운 것부터, 원본을 바꾸지 않는 방식으로 수집하고, 누가 언제 다뤘는지 기록해야 합니다.
- 휘발성 순서: 메모리 → 실행 중 프로세스·네트워크 연결 → 디스크 → 원격 로그·백업 순으로 확보합니다.
- 무결성: 디스크 이미지와 로그 파일은 해시값(예:
sha256sum)을 남기고 사본으로 분석합니다. - 인수인계 기록: 수집자, 시각, 보관 위치, 전달 대상을 기록해 두면 수사 의뢰나 분쟁 때 증거 능력을 지키는 데 도움이 됩니다.
- 재설치 금지: 증거 확보 전에 서버를 포맷하거나 이미지를 새로 배포하지 않습니다. 복구가 급하면 새 환경을 따로 만들어 전환합니다.
- 클라우드: 감사 로그(예: CloudTrail, Azure Activity Log)와 스냅숏을 별도 계정이나 잠금 저장소로 복사합니다.
# 예시: 로그 묶음을 보존하고 해시 기록
tar czf evidence-web01-20261109.tar.gz /var/log/nginx /var/log/auth.log
sha256sum evidence-web01-20261109.tar.gz >> evidence-hashes.txt침해사고 신고 의무는 어떻게 되나요?
정보통신서비스 제공자는 침해사고를 알게 된 때부터 24시간 이내에 과기정통부 또는 KISA에 신고해야 하고, 개인정보가 유출됐다면 개인정보 보호법에 따라 72시간 이내 통지·신고 의무를 따로 확인해야 합니다.
정보통신망법 침해사고 신고
정보통신망법 제48조의3과 시행령에 따라 정보통신서비스 제공자는 침해사고 발생 사실을 과기정통부 또는 KISA에 신고해야 합니다. 2024년 8월 14일 시행된 시행령 개정으로 "사고를 인지한 이후 24시간 이내"에 그때까지 파악된 피해 내용, 원인, 대응 현황을 우선 신고(최초 신고)하고, 이후 확인된 사항은 확인 시점부터 24시간 이내에 보완 신고하도록 구체화됐습니다. KISA도 공지에서 "침해사고 발생을 알게 된 때로부터 24시간 이내 신고하여야 합니다"라고 안내합니다.
또한 2026년 3월 12일 국회를 통과한 정보통신망법 개정안은 24시간 신고 기한을 법률 조문에 명시하고, 대통령령으로 정하는 침해사고는 이용자에게 지체 없이 통지하도록 하는 의무를 신설했습니다. 보도에 따르면 이 부분은 공포 후 6개월이 지나 시행되므로, 구체적인 시행일과 통지 대상 사고의 범위는 법제처에서 최신 법령을 확인하세요. 신고는 보호나라(KISA)의 침해사고 신고 창구로 합니다.
개인정보 보호법 유출 통지·신고
개인정보보호위원회 안내에 따르면 개인정보처리자는 개인정보 보호법 제34조와 시행령 제40조에 따라 다음 중 하나에 해당하면 유출 사실을 알게 된 때부터 72시간 이내에 신고해야 합니다. 신고는 개인정보보호위원회가 지정한 KISA로, 개인정보 포털(brss.pipc.go.kr)을 통해 합니다.
- 1천명 이상 정보주체의 개인정보가 유출된 경우
- 민감정보 또는 고유식별정보가 유출된 경우
- 외부의 불법 접근으로 개인정보처리시스템이나 업무용 단말기에서 개인정보가 유출된 경우
정보주체 통지는 시행령 제39조에 따라 유출을 알게 된 때부터 72시간 이내에 하는 것이 원칙입니다. 개인정보보호위원회는 신고하지 않으면 3천만원 이하의 과태료(법 제75조 제2항 제18호)가 부과될 수 있다고 안내합니다. 금융회사·신용정보회사 등은 신용정보법에 따른 별도 기준이 있으므로 업권 규정을 함께 확인해야 합니다.
사고 중 커뮤니케이션은 어떻게 해야 하나요?
사실만, 정해진 창구 하나로, 정해진 주기로 알리는 것이 원칙입니다.
- 내부: 대응 상황은 별도 채널(공격자가 메일·메신저를 볼 수 있다고 가정)에서 공유하고, 경영진 보고 주기를 정합니다.
- 고객: 확인된 사실, 고객이 할 일(비밀번호 변경 등), 문의 창구를 담습니다. 추정 원인이나 "피해 없음" 같은 단정은 조사 전에는 쓰지 않습니다.
- 기관: 최초 신고 후 바뀐 사실은 보완 신고로 갱신합니다.
- 협력사: 위탁사·클라우드 사업자·보안관제 업체에 같은 사실을 같은 시점에 전달합니다.
보안팀이 없는 조직은 어떻게 대비하나요?
매뉴얼과 역할표는 내부에서 만들고, 24시간 탐지와 초기 분석은 외부 보안관제(MDR) 서비스로 보완하는 방식이 현실적입니다.
사고 대응에서 가장 시간이 많이 새는 구간은 "이상 징후를 누군가 알아채기까지"입니다. MDR은 로그와 경보를 전문 인력이 모니터링하고 분석 결과와 초기 조치 권고를 전달하는 서비스입니다(MDR이란? 보안관제와 차이). 씨커스랩의 KYRA MDR은 보안 전담 인력이 없는 기업을 위해 업무시간 플랜과 24/7 전문가 모니터링 플랜을 공개 가격으로 제공하며, kyramdr.com에서 무료로 시작해 볼 수 있습니다. 외부 서비스를 쓰더라도 신고 판단과 고객 공지는 회사의 결정이므로, 매뉴얼의 RACI에 관제 업체와의 연락·인계 절차를 반드시 적어 두세요.
한눈에 정리
- 침해사고는 해킹·악성코드·서비스 거부 공격 등으로 정보통신망이나 시스템을 공격해 발생한 사태입니다.
- 대응 절차의 뼈대는 NIST 4단계(준비, 탐지·분석, 격리·제거·복구, 사후 활동)이며, 국내 7단계 모델과 대응시켜 쓸 수 있습니다.
- 매뉴얼에는 조직·역할, 심각도 기준, 단계별 절차, 신고 기준, 증거 보존, 소통, 연락망, 양식이 들어가야 합니다.
- 정보통신서비스 제공자는 침해사고를 알게 된 때부터 24시간 이내에 KISA 등에 최초 신고합니다.
- 개인정보 유출이 기준(1천명 이상, 민감·고유식별정보, 외부 불법 접근)에 해당하면 72시간 이내에 신고합니다.
- 증거는 휘발성 순서로, 해시와 인수인계 기록을 남기며 수집합니다.
자주 묻는 질문
침해사고 대응 매뉴얼과 절차서는 다른 문서인가요?
혼용해서 쓰는 경우가 많습니다. 구분한다면 매뉴얼은 조직·원칙·기준을 담은 상위 문서이고, 절차서는 단계별 작업 순서와 양식을 담은 실행 문서입니다. 작은 조직은 한 문서로 합쳐도 충분합니다.
침해사고 대응 7단계와 NIST 4단계 중 무엇을 써야 하나요?
어느 쪽이든 괜찮습니다. 내부 감사나 인증 심사에서 요구하는 기준이 있으면 그것을 따르고, 없다면 이해하기 쉬운 NIST 4단계를 뼈대로 쓰고 7단계의 초기 대응·대응 전략 체계화를 세부 절차로 넣는 방식을 권합니다.
원인을 모르는데 24시간 안에 신고해야 하나요?
2024년 시행령 개정 취지는 원인 분석 때문에 신고가 늦어지지 않도록 파악된 내용으로 먼저 신고하고, 추가 사항은 보완 신고하게 하는 것입니다. 원인이 확정될 때까지 기다리지 말고 KISA 안내를 따르세요.
개인정보가 몇 건만 유출돼도 신고해야 하나요?
1천명 미만이라도 민감정보나 고유식별정보가 포함됐거나 외부 불법 접근으로 유출됐다면 신고 대상입니다. 신고 대상이 아니어도 정보주체 통지 의무는 별도로 검토해야 하므로 개인정보보호위원회 안내를 확인하세요.
매뉴얼은 얼마나 자주 고쳐야 하나요?
법정 주기가 정해진 것은 아니지만, 연락처는 분기마다, 전체 절차는 모의훈련이나 실제 사고 뒤와 법령 개정 시마다 점검하는 것이 일반적입니다. 개정 이력을 문서 끝에 남겨 두세요.
참고 자료
- 법제처 국가법령정보센터 – 정보통신망 이용촉진 및 정보보호 등에 관한 법률
- 법제처 국가법령정보센터 – 개인정보 보호법 시행령
- 개인정보보호위원회 – 개인정보 유출 신고 안내
- 보안뉴스 – 과기정통부, 정보통신망법 개정안 시행 (2024-08-13)
- 법률신문 – 정보통신망법 개정안 국회 본회의 통과 (2026)
- NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- IT위키 – 침해사고 대응절차 (7단계 모델)
