침해사고 대응 보고서에 들어가야 할 항목 : 12가지만 먼저 잡으세요

이 글이 필요한 팀과 다른 대응이 필요한 경우

이 글은 침해사고가 발생했거나 의심되는 상황에서 사내 공유용 초기 보고서, 경영진 보고서, 기술 대응 기록을 만들어야 하는 조직에 적합합니다. 직원 PC 악성코드 감염, 관리자 계정 탈취, 서버 해킹, 랜섬웨어, 웹셸 발견, 비정상 로그인, 데이터 유출 의심 같은 상황이 대표적입니다.

직원 PC 한 대에서 시작된 사고라면

먼저 단말을 격리하고 감염 범위를 확인한 뒤, 최초 발견 시각과 조치 시각을 기록해야 합니다. 구체적인 초기 대응 순서는 직원 PC 악성코드 감염 대응 가이드와 함께 확인하면 좋습니다.

이 글만으로 부족한 상황도 있습니다

대규모 개인정보 유출, 결제정보 침해, 주요 서버 전체 암호화, 내부자 연루 의심, 증거 훼손 가능성, 수사기관 제출 가능성이 있는 사건은 일반적인 사내 보고서만으로 대응하기 어렵습니다. 이런 경우에는 디지털 포렌식, 개인정보보호, 법률, 보험 담당자가 같은 타임라인을 공유하도록 하는 편이 안전합니다.

침해사고 대응 보고서에 넣을 12개 항목

초기 보고서를 처음부터 긴 문장으로 작성할 필요는 없습니다. 아래 12개 칸을 먼저 만들고, 확인된 내용부터 채우는 방식이 훨씬 빠릅니다.

항목	보고서에 기록할 내용
1. 문서 기본정보	사고번호, 문서 버전, 작성자, 작성·수정 시각, 보안등급
2. 사고 요약	무슨 일이 발생했고 현재 어떤 상태인지 3~5문장으로 요약
3. 인지 정보	최초 탐지 시각, 인지 시각, 신고자 또는 탐지 시스템
4. 사고 유형	악성코드, 계정 탈취, 웹 해킹, 랜섬웨어, 정보 유출 의심 등
5. 영향 자산	PC, 서버, 계정, 홈페이지, 데이터베이스, 클라우드 등
6. 상세 타임라인	탐지·확인·격리·차단·복구·신고 시각
7. 원인과 침투경로	확정된 원인과 현재 조사 중인 가설을 분리
8. 피해 범위	영향 시스템 수, 계정 수, 서비스 중단, 유출 가능 데이터 등
9. 증거와 로그	접속 로그, 인증 로그, 보안장비 로그, 악성파일, IP, 도메인 등
10. 대응 조치	격리, 계정 차단, 비밀번호 변경, 취약점 수정, 복구 현황
11. 신고·커뮤니케이션	관계기관 신고, 고객 통지 검토, 협력업체·보험사 연락 현황
12. 재발방지 계획	추가 조치, 담당자, 완료 예정일, 확인 방법

잠깐, 모르는 내용을 채우지 마세요

사고 초기에 공격자의 최초 침투경로나 실제 유출 규모를 확정하기 어려운 것은 이상한 일이 아닙니다. 이런 항목에는 공란 대신 ‘조사 중’, ‘현재까지 확인되지 않음’, ‘추가 로그 분석 필요’처럼 상태를 기록하세요.

특히 ‘유출 없음’과 ‘유출 증거를 아직 발견하지 못함’은 전혀 다른 문장입니다. 사고 보고서에서는 이 차이가 큽니다.

시간부터 쓰세요: 타임라인이 보고서의 뼈대입니다

침해사고 보고서에서 가장 먼저 정리할 것은 원인보다 시간입니다. 원인은 조사하면서 바뀔 수 있지만 누가 무엇을 언제 발견하고 조치했는지는 시간이 지나면 오히려 복원하기 어려워집니다.

최소 여섯 시각을 따로 기록하세요

• 이상 징후가 최초로 발생한 것으로 추정되는 시각
• 보안 시스템이나 직원이 처음 탐지한 시각
• 담당자가 침해 가능성을 인지한 시각
• PC·서버·계정을 처음 격리하거나 차단한 시각
• 내부 책임자에게 보고한 시각
• 외부 신고나 고객 통지가 이루어진 시각

대부분 여기서 잘못 판단합니다

‘사고 발생 시각’과 ‘사고 인지 시각’을 하나로 쓰는 실수가 많습니다. 공격자가 새벽 2시에 접속했지만 회사가 오전 10시에 이상 징후를 확인했다면 두 시각은 분리해 기록해야 합니다.

관계기관 신고기한을 검토해야 하는 사고라면 인지 시점을 뒷받침할 메일, 티켓, 보안 경보, 메신저 기록도 함께 보관하는 편이 좋습니다.

실제 적용 사례

월요일 오전 9시 12분, 직원이 파일 서버의 일부 문서가 열리지 않는다고 전산 담당자에게 연락했다고 가정해 보겠습니다. 담당자는 9시 20분 서버에서 비정상 파일 확장자를 확인하고 9시 27분 네트워크를 격리했습니다.

로그를 확인해 보니 의심스러운 관리자 로그인은 새벽 3시 41분부터 남아 있었습니다. 이때 보고서에는 ‘사고 발생 추정 03:41’, ‘최초 사용자 신고 09:12’, ‘침해 인지 09:20’, ‘서버 격리 09:27’처럼 각각 기록합니다.

오후 조사에서 더 오래된 침투 흔적이 발견되면 최초 침투 추정 시각만 수정하고, 기존에 기록한 탐지·인지·격리 시각은 그대로 유지합니다. 이렇게 작성하면 보고서가 조사 과정 자체를 보여주는 기록이 됩니다.

피해 범위는 숫자로: 어디까지 확인됐는지 구분하세요

‘일부 PC 감염’, ‘고객정보 유출 가능성 있음’ 같은 표현만으로는 경영진도 기술팀도 제대로 판단하기 어렵습니다. 가능한 범위에서 수치와 대상을 함께 적어야 합니다.

범위	확인할 내용	기록 예시
단말	감염·의심 PC 수	전체 63대 중 2대 감염 확인, 4대 조사 중
서버	영향 서버와 서비스	파일 서버 1대 암호화, ERP 서버 영향 미확인
계정	탈취 또는 오용 가능 계정	관리자 계정 1개 비정상 로그인 확인
데이터	접근·조회·다운로드 가능성	고객 DB 접근 로그 조사 중
업무	서비스 중단 시간	주문 처리 약 47분 중단
금전	송금·결제·복구 비용	현재 직접 손실 확인 없음

개인정보가 있다면 항목과 사람 수를 나눕니다

개인정보 유출 가능성이 있다면 ‘개인정보 있음’으로 끝내지 말고 성명, 연락처, 로그인 정보, 결제 관련 정보, 고유식별정보 등 데이터 종류를 분리하고 영향을 받을 가능성이 있는 정보주체 규모를 조사해야 합니다.

유출 여부를 판단할 때는 웹 서버나 데이터베이스의 접속기록이 핵심 단서가 될 수 있습니다. 로그 확인 방법은 고객정보 유출 시 로그 확인 항목도 함께 참고할 수 있습니다.

증거는 건드리지 마세요: 로그와 원본을 먼저 보전합니다

침해사고 대응에서 가장 아쉬운 장면은 공격 흔적을 찾으려다 공격 흔적 자체를 지워버리는 경우입니다. 감염 PC를 무작정 초기화하거나 서버 로그를 정리하면 나중에 침투경로와 피해 범위를 확인하기 어려워질 수 있습니다.

보고서에 증거 목록을 따로 만드세요

• 운영체제와 서버 이벤트 로그
• 방화벽·웹방화벽·EDR·백신 경보 기록
• VPN·메일·클라우드·관리자 로그인 기록
• 웹 서버와 데이터베이스 접속 기록
• 악성으로 의심되는 파일과 파일명·경로
• 의심 IP 주소, 도메인, URL
• 피싱 메일 원본과 첨부파일 정보
• 직원이 촬영한 화면이나 오류 메시지
• 각 자료를 확보한 사람과 확보 시각

그런데 실제로는 다릅니다

‘증거를 보전한다’는 말이 모든 시스템을 그대로 켜두라는 뜻은 아닙니다. 피해 확산을 막기 위해 네트워크 차단이나 계정 비활성화가 먼저 필요할 수도 있습니다. 중요한 것은 어떤 조치를 왜 했으며 그 전에 무엇을 확보했는지를 기록하는 것입니다.

수사기관 신고나 분쟁 가능성이 있다면 확보한 증거의 원본성, 전달 경로, 담당자 기록이 더 중요해질 수 있습니다. 관련 준비는 해킹 피해 경찰 신고 시 준비할 증거자료에서 별도로 확인할 수 있습니다.

조금 더 깊이 알고 싶다면

기술 조사에서는 침해지표라고 부르는 흔적을 모으기도 합니다. 악성 IP, 도메인, 파일 해시, 비정상 프로세스, 특정 레지스트리 값, 계정 로그인 패턴 등이 여기에 포함될 수 있습니다.

보고서에는 이런 값을 무조건 많이 넣기보다 ‘어떤 시스템에서 발견됐고, 다른 시스템에서도 검색했으며, 추가 발견 여부가 어땠는지’를 함께 기록해야 실제 대응에 도움이 됩니다.

조치 내역은 결과까지: 차단·제거·복구를 분리하세요

‘보안 조치 완료’라는 한 줄은 가장 편하지만 가장 쓸모가 적은 기록입니다. 침해사고 대응은 최소한 확산 차단, 원인 제거, 정상화, 후속 모니터링으로 나눠 기록하는 편이 좋습니다.

단계	대표 조치	보고서에 추가할 정보
격리	네트워크 차단, 계정 잠금	시각, 대상, 담당자
확산 방지	악성 IP 차단, 권한 회수	다른 시스템 적용 여부
원인 제거	악성파일 제거, 취약점 패치	원인이 실제로 제거됐는지 확인 방법
복구	백업 복원, 서비스 재가동	복구 기준 시점과 검증 결과
모니터링	추가 로그인·트래픽 감시	모니터링 기간과 담당자

담당자와 완료 시각이 없으면 ‘할 일’일 뿐입니다

각 대응 조치에는 담당자, 시작 시각, 완료 시각, 확인 방법을 붙이세요. 아직 완료되지 않았다면 상태를 ‘진행 중’으로 표시하고 다음 확인 예정 시각을 기록합니다.

복구했다고 끝난 것이 아닙니다

백업으로 서버를 복구했더라도 공격자가 사용한 취약점이나 탈취 계정이 그대로 남아 있다면 같은 침투가 반복될 수 있습니다. 그래서 복구와 원인 제거는 별도 항목으로 남기는 편이 좋습니다.

24시간과 72시간은 같은 시계가 아닙니다

침해사고가 발생했다고 해서 모든 기업이 동일한 기관에 같은 방식으로 신고하는 것은 아닙니다. 정보통신망법상 대상이 되는 정보통신서비스 제공자의 침해사고 신고와 개인정보 보호법상 개인정보 유출 등의 신고·통지는 각각 적용 대상과 기준을 따로 검토해야 합니다.

현재 KISA 신고 안내는 정보통신서비스 제공자의 침해사고 신고에 대해 사고 발생을 알게 된 때부터 24시간 이내 신고하도록 안내하고 있으며, 최초 신고 후 추가 사실이 확인되는 경우에도 보완 신고가 필요할 수 있습니다. 신고 항목에는 발생 일시·원인·피해내용, 대응 현황, 담당 부서와 연락처가 포함됩니다.

개인정보 유출 등의 경우에는 별도 기준을 확인해야 합니다. 개인정보 보호법 시행령은 일정한 신고 대상 사고에 대해 개인정보 유출 등을 알게 된 때부터 72시간 이내 신고하도록 규정하고 있으며, 구체적인 내용이 아직 확인되지 않았다면 확인된 내용을 우선 신고한 뒤 추가 사실을 보완하는 구조를 두고 있습니다.

구분	보고서에서 확인할 핵심	주의할 점
사내 사고 보고	인지 시각, 피해, 대응, 원인, 후속조치	회사 내부 절차에 맞게 즉시 공유
침해사고 신고 검토	사업자 유형, 인지 시각, 사고 내용	24시간 기준 적용 여부를 우선 확인
개인정보 유출 신고·통지 검토	유출 항목, 규모, 경로, 정보주체 영향	침해사고 신고와 별개로 판단
수사·보험 검토	범죄 정황, 금전피해, 증거자료, 보험 약관	계약과 사건 상황에 따라 절차가 달라짐

잠깐, ‘확정된 뒤 신고’라고 생각하면 늦을 수 있습니다

침해사고 초기에는 원인과 피해 규모가 완전히 나오지 않는 경우가 많습니다. 따라서 보고서에는 ‘최초 인지 시각’을 명확하게 기록하고, 법정 신고 대상 가능성이 있다면 조사가 끝날 때까지 기다리지 말고 적용 기준을 먼저 확인하는 편이 안전합니다.

KISA 신고 절차가 필요한지 애매하다면 KISA 118 사이버사고 신고 가이드도 함께 확인할 수 있습니다.

보고서가 약해지는 흔한 실수

실수 1. 사실과 추정을 한 문장에 섞습니다

‘피싱메일을 통해 해킹되어 고객정보가 유출됨’이라고 적었지만 실제로는 피싱메일도, 데이터 반출도 아직 확인되지 않았을 수 있습니다. 이런 경우에는 ‘피싱메일을 통한 계정 탈취 가능성 조사 중’, ‘외부 반출 여부 로그 분석 중’으로 나눠야 합니다.

실수 2. 시스템을 먼저 초기화합니다

업무 복구가 급하다는 이유로 감염 PC나 서버를 즉시 포맷하면 중요한 로그와 공격 흔적을 잃을 수 있습니다. 확산 방지를 우선하되 증거 확보가 필요한 사건인지 먼저 판단해야 합니다.

실수 3. ‘조치 완료’만 기록합니다

누가 언제 무엇을 했는지 없는 보고서는 나중에 사실관계를 재구성하기 어렵습니다. 계정 비활성화, 네트워크 격리, 패치, 복구, 비밀번호 변경 각각에 시간을 붙이세요.

실수 4. 보고서를 한 번 쓰고 닫습니다

침해사고 보고서는 사고 당일 작성한 1회성 문서라기보다 조사와 함께 갱신되는 기록에 가깝습니다. ‘초기보고’, ‘중간보고’, ‘최종보고’처럼 버전을 관리하면 처음의 추정이 나중에 확정 사실처럼 남는 문제를 줄일 수 있습니다.

외부 전문가의 도움이 필요한 경우

작은 악성코드 감염까지 모두 외부 포렌식 업체에 맡길 필요는 없습니다. 반대로 사고 규모가 큰데 비용을 아끼기 위해 내부 인력만으로 처리하다가 로그 보전이나 신고 판단을 놓치는 것도 위험합니다.

상황	내부 대응 중심	외부 도움 검토
단일 PC 악성코드	격리와 기본 로그 분석이 가능하고 확산 징후가 없음	관리자 계정 탈취나 내부 확산이 의심됨
홈페이지 침해	침투 지점과 변경 파일을 명확히 확인	웹셸·DB 접근·장기 잠복 가능성이 있음
랜섬웨어	일부 단말에 한정되고 백업·원인이 확인됨	서버 다수 암호화, 데이터 탈취 협박, 백업 훼손
개인정보	접근 범위와 영향이 명확함	민감정보·대량정보·외부 반출 가능성이 있음
분쟁·수사	일반 사내 기록 목적	수사기관·소송·보험 제출 가능성이 있음

디지털 포렌식을 검토할 신호

• 공격자의 최초 침투 시점을 특정하기 어렵습니다.
• 관리자 권한이 탈취됐을 가능성이 있습니다.
• 여러 서버와 PC로 공격이 확산됐습니다.
• 데이터 외부 반출 여부를 판단하기 어렵습니다.
• 공격자가 로그를 삭제하거나 변조한 정황이 있습니다.
• 수사기관이나 보험사에 자료를 제출할 가능성이 있습니다.

업체에 견적을 받을 때 물어볼 질문

• 조사 대상 장비와 서버 수를 어떻게 산정하는가?
• 로그 분석과 디스크 포렌식은 견적에 모두 포함되는가?
• 침투경로와 정보 유출 여부를 어디까지 분석하는가?
• 중간 보고와 최종 보고서를 각각 제공하는가?
• 증거 원본과 분석 자료는 어떤 방식으로 보관하는가?
• 재발방지 권고와 복구 지원은 별도 비용인가?
• 관계기관 신고에 필요한 기술자료 작성 지원이 가능한가?

호스팅이나 외부 운영업체가 얽힌 사고라면 어떤 자료를 요청해야 할지도 미리 정리할 필요가 있습니다. 이 경우 침해사고 발생 시 호스팅 업체에 문의할 항목을 함께 확인하면 조사 범위를 잡는 데 도움이 됩니다.

자주 묻는 질문

침해사고 대응 보고서는 몇 페이지로 작성해야 하나요?

정해진 분량보다 정보 구조가 중요합니다. 초기 보고는 1~3페이지 정도로 핵심 사실과 즉시 조치를 중심으로 만들 수 있고, 로그 분석과 포렌식 결과가 쌓이면 별도의 기술 부록이나 최종 보고서를 추가하는 방식이 실무적으로 편합니다.

원인을 아직 모르면 보고서를 작성하지 않아도 되나요?

오히려 초기 보고서를 먼저 만드는 편이 좋습니다. 원인에는 ‘조사 중’이라고 표시하고 현재 확인된 사실, 인지 시각, 영향 시스템, 긴급 조치를 우선 기록하세요. 이후 확인된 사실을 버전별로 추가하면 됩니다.

침해 흔적이 발견됐지만 실제 피해가 없으면 보고서가 필요한가요?

피해가 확인되지 않았다는 사실 역시 기록할 가치가 있습니다. 무엇을 조사했고 어떤 근거로 현재 피해가 확인되지 않았다고 판단했는지 남겨야 나중에 새로운 흔적이 발견됐을 때 비교할 수 있습니다.

직원 이름을 사고 보고서에 적어도 되나요?

사고 대응에 필요한 범위인지 먼저 판단하세요. 직원의 실수를 강조하기보다 계정명, 담당 역할, 조치 내용처럼 사고 분석에 필요한 정보 중심으로 작성하고 보고서 접근 권한도 제한하는 편이 좋습니다.

사고 보고서와 개인정보 유출 안내문은 같은 문서인가요?

목적이 다릅니다. 사고 보고서는 내부 대응과 원인 분석을 위한 기술·관리 기록이고, 개인정보 유출 통지는 정보주체에게 필요한 정보를 전달하기 위한 문서입니다. 내부 보고서 내용을 바탕으로 통지문을 작성할 수 있지만 그대로 복사하는 것은 적절하지 않을 수 있습니다.

최종 보고서는 언제 작성하는 것이 좋나요?

핵심 침투경로, 피해 범위, 복구 결과가 충분히 확인되고 주요 후속조치가 정해진 시점에 작성하는 것이 일반적입니다. 다만 모든 재발방지 조치가 끝날 때까지 기다리기보다 미완료 과제와 담당자·기한을 명확하게 남길 수 있습니다.

침해사고 신고를 하면 경찰 신고도 자동으로 되나요?

관계기관별 신고 목적과 절차는 서로 다를 수 있습니다. 범죄 수사나 금전 피해 회복을 위해 경찰 신고가 필요한 상황이라면 KISA 신고와 별도로 검토하세요. 특히 계좌이체, 사칭 이메일, 랜섬웨어 협박처럼 범죄 피해가 분명한 사건은 증거자료를 먼저 정리하는 편이 좋습니다.

보고서에 공격자의 IP 주소를 모두 넣어야 하나요?

경영진용 본문에 모든 기술 데이터를 넣을 필요는 없습니다. 핵심 침해지표와 의미만 본문에 정리하고 대량의 IP, 로그, 파일 해시 등은 기술 부록으로 분리하면 가독성과 활용성을 함께 확보할 수 있습니다.

지금 15분 안에 보고서 뼈대를 만드세요

지금 사고 대응 중이라면 빈 문서에 긴 서론부터 쓰지 마세요. 아래 12개 제목을 복사해 놓고 확인된 사실만 한 줄씩 입력하는 것이 첫 행동입니다.

1. 사고번호와 문서 버전
2. 사고 요약
3. 최초 탐지·인지 시각
4. 사고 유형
5. 영향받은 시스템과 계정
6. 상세 타임라인
7. 원인과 침투경로
8. 피해 및 정보 유출 범위
9. 확보한 로그와 증거
10. 격리·차단·복구 조치
11. 관계기관·고객·협력사 연락 현황
12. 재발방지 담당자와 완료 기한

그리고 문서 첫 페이지에 ‘확인된 사실 / 조사 중 / 미확인’이라는 세 가지 상태 표시를 정하세요. 이 작은 구분이 사고 초기의 혼란을 상당히 줄여 줍니다.

최종 검토: 2026-08