KISA 118 사이버사고 신고 기준 24시간을 놓치지 않는 대응법

118보다 다른 창구가 먼저인 상황부터 구분하세요

KISA 118은 해킹, 악성코드, 스미싱, 피싱사이트, 계정 탈취와 같은 사이버 문제를 상담할 수 있는 대표 창구입니다. 다만 상담을 받는 것과 법정 신고, 경찰 수사, 금융회사 지급정지는 서로 다른 절차입니다.

온라인 서비스를 운영하는 사업자

쇼핑몰, 커뮤니티, 예약 서비스, 교육 플랫폼, 모바일 앱, 서비스형 소프트웨어, 호스팅 서비스를 운영한다면 정보통신서비스 제공자에 해당하는지 먼저 검토해야 합니다. 직원 수가 적거나 정보기술 기업이 아니라는 이유만으로 신고 의무가 사라지는 것은 아닙니다.

온라인 주문을 받는 제조업체나 회원 계정을 운영하는 오프라인 사업자도 실제 서비스 구조에 따라 판단이 달라질 수 있습니다. 사업자등록증의 업종명보다 이용자에게 어떤 정보통신서비스를 제공하는지가 더 중요한 단서가 됩니다.

개인은 118 상담이 출발점이 될 수 있습니다

개인 컴퓨터나 스마트폰의 랜섬웨어 감염, 악성 앱, 계정 탈취, 피싱 의심 상황이라면 국번 없이 118에서 대응 방법을 안내받을 수 있습니다. KISA는 해킹·바이러스 긴급상담을 365일 24시간 운영하고 있으며, 개인정보 일반상담과 채팅상담은 운영시간이 다릅니다. :contentReference[oaicite:1]{index=1}

돈이 빠져나갔다면 금융회사와 경찰 조치가 먼저입니다

보이스피싱, 스미싱 송금, 계좌 탈취, 가상자산 전송, 협박성 금전 요구가 발생했다면 KISA 상담만으로 자금 회수를 기대해서는 안 됩니다. 거래 금융회사에 지급정지 가능성을 문의하고 경찰 신고와 증거 보존을 함께 진행해야 합니다.

상황	우선 확인할 창구	함께 해야 할 조치
기업 서버 해킹·랜섬웨어·디도스	KISA 침해사고 신고	격리, 로그 보존, 내부 보고
개인 PC 악성코드·피싱 의심	KISA 118 상담	계정 보호, 비밀번호 변경, 악성코드 점검
송금·계좌·카드 금전 피해	금융회사와 경찰	지급정지 문의, 거래내역 보존
개인정보 유출	개인정보 유출신고 시스템	정보주체 통지와 침해사고 신고 별도 검토
금융·의료·통신·공공 분야	해당 감독기관과 내부 보고체계	KISA 신고와 중복 여부 확인

신고 의무는 피해액보다 사업자 지위에서 먼저 갈립니다

침해사고 신고 여부를 판단할 때 “얼마나 큰 피해가 났는가”만 보는 것은 위험합니다. 현재 KISA 안내는 정보통신서비스 제공자가 침해사고 발생을 알게 된 때부터 24시간 이내에 신고하도록 설명하고 있습니다. 늦게 신고하거나 신고하지 않으면 정보통신망법에 따라 3천만원 이하 과태료 대상이 될 수 있습니다. :contentReference[oaicite:2]{index=2}

세 가지 질문으로 신고 검토 대상을 좁힙니다

1. 우리 회사가 정보통신망을 이용해 이용자에게 정보나 서비스를 제공하거나 그 제공을 매개하는가?
2. 단순 오류가 아니라 비인가 접근, 악성코드, 공격 트래픽, 인증 우회 등 침해 정황이 있는가?
3. 사고 가능성을 직원, 관제업체, 이용자, 호스팅업체로부터 통보받은 시각이 언제인가?

세 질문 중 첫째와 둘째가 모두 해당한다면 피해 규모가 작아 보여도 신고 대상 검토를 미루지 않는 편이 안전합니다. 법률상 의무 주체가 불분명하다면 법무 담당자나 관련 기관에 확인하되, 그 확인 과정 때문에 24시간 기록이 멈추는 것은 아닙니다.

호스팅사나 외주업체가 신고해도 끝났다고 단정하지 마세요

서비스 운영사, 클라우드 사업자, 호스팅사, 외주 개발사는 동일한 사고를 서로 다른 위치에서 발견할 수 있습니다. 계약서에 신고 대행 권한이 명확한지, 어느 법인의 이름으로 접수했는지, 제출한 사고 범위가 자사 시스템까지 포함하는지 확인해야 합니다.

다른 법률에 따라 이미 통지하거나 신고한 경우 정보통신망법상 신고로 인정될 가능성이 있지만, 모든 산업 신고가 자동으로 대체되는 것은 아닙니다. 감독기관, 적용 법률, 접수 내용과 정보 공유 구조를 확인한 뒤 판단해야 합니다.

랜섬웨어가 아니어도 침해사고가 될 수 있습니다

침해사고는 화면에 협박문이 뜨는 랜섬웨어나 대규모 디도스만 의미하지 않습니다. 정보통신망법은 해킹, 컴퓨터바이러스, 논리폭탄, 메일폭탄, 서비스거부 공격뿐 아니라 정상적인 보호·인증 절차를 우회하게 하는 프로그램이나 기술적 장치로 발생한 사태까지 폭넓게 다룹니다.

관리자 계정 탈취와 인증 우회

클라우드 관리자, 쇼핑몰 관리자, 가상사설망 계정, 원격접속 계정이 탈취된 경우를 생각해 볼 수 있습니다. 다중인증이 꺼졌거나 새로운 인증수단이 등록됐고, 낯선 지역에서 로그인한 흔적이 있다면 단순 비밀번호 분실로 처리하지 마세요.

회사 이메일 계정의 비인가 접속이 의심된다면 회사 이메일 계정 탈취 대응 절차를 함께 확인해 로그인 세션, 전달 규칙, 복구 수단 변경 이력을 점검하는 것이 좋습니다.

웹셸·백도어·비인가 프로그램 설치

웹셸은 공격자가 서버에서 명령을 실행하거나 파일을 올리기 위해 남기는 비인가 파일입니다. 백도어 계정, 예약 작업, 악성 플러그인, 알 수 없는 원격관리 프로그램도 공격자가 다시 들어올 통로가 될 수 있습니다.

워드프레스 사이트라면 악성코드 제거 가격만 비교하기 전에 침투 경로, 변조 파일, 관리자 계정, 데이터베이스 변경, 재감염 방지 범위가 견적에 포함되는지 확인해야 합니다. 관련 비용 구조는 워드프레스 악성코드 제거 비용 비교 기준에서 더 자세히 살펴볼 수 있습니다.

서비스 장애와 공격을 구분하는 단서

확인 항목	단순 장애 가능성	침해사고 의심 단서
접속량	정상 범위 또는 배포 직후 증가	다수 국가·주소에서 비정상 요청 급증
계정 기록	내부 작업자 로그인과 일치	낯선 위치, 새 기기, 비정상 시간대 접속
파일 변경	정상 배포 파일만 변경	웹셸, 난독화 코드, 알 수 없는 실행파일
설정 변경	승인된 작업표와 일치	방화벽 해제, 인증수단 삭제, 새 관리자 생성
외부 통신	등록된 서비스 주소와 통신	알 수 없는 서버로 반복 연결 또는 대량 전송

조금 더 깊이 알고 싶다면

취약점이 존재한다는 사실과 침해사고가 발생했다는 사실은 구분해야 합니다. 업데이트하지 않은 플러그인이 있다는 것만으로 실제 침해가 확정되는 것은 아니지만, 해당 취약점을 이용한 로그인·파일 생성·명령 실행 흔적이 확인되면 판단이 달라집니다.

따라서 취약점 목록만 보지 말고 웹 접근기록, 관리자 활동기록, 파일 변경 시각, 외부 통신 기록을 시간순으로 맞춰 보아야 합니다. 여러 기록이 같은 시각에 겹칠수록 실제 침해 가능성이 높아집니다.

24시간은 원인 확정이 아니라 사고 인지부터 계산합니다

신고기한의 출발점은 포렌식 보고서가 완성된 시각이나 대표이사가 신고를 승인한 시각이 아닙니다. 시행령은 침해사고 발생을 알게 된 때부터 24시간 이내에 발생 일시, 원인·피해내용, 대응 현황, 담당 부서와 연락처를 신고하도록 정하고 있습니다. 신고 후 추가로 확인된 사실도 확인한 때부터 24시간 이내에 보완 신고해야 합니다. :contentReference[oaicite:3]{index=3}

사고 발생 시각과 최초 인지 시각을 나누어 적습니다

공격이 시작된 것은 월요일 새벽이지만 보안 담당자가 알아챈 것은 수요일 오전일 수 있습니다. 신고기한 계산을 위해서는 두 시간을 한 칸에 섞지 말고 별도로 기록해야 합니다.

• 추정 발생 시각: 현재 로그에서 확인되는 최초 공격 또는 이상 행위 시각
• 최초 인지 시각: 직원, 이용자, 보안관제, 외주업체가 사고 가능성을 처음 알린 시각
• 내부 보고 시각: 보안책임자, 개인정보보호책임자, 경영진에게 보고한 시각
• 신고 시각: KISA 등에 신고 내용을 전달한 시각
• 접수 확인 시각: 접수번호나 접수완료 상태를 확인한 시각

실제 적용 사례: 원인 분석을 기다리다 시계를 놓친 쇼핑몰

화요일 오전 9시, 한 쇼핑몰 운영자는 고객으로부터 결제 페이지가 이상한 주소로 이동한다는 연락을 받았습니다. 담당자는 광고 스크립트 오류일 가능성이 높다고 생각했고, 개발사에 점검을 요청했습니다.

오후 4시가 되어서야 서버에서 변조된 자바스크립트 파일과 낯선 관리자 계정이 발견됐습니다. 다음 날 포렌식 업체는 최초 침투 시점이 전주 금요일일 수 있다고 설명했지만, 정확한 유출 범위는 아직 알 수 없었습니다.

이 상황에서 가장 중요한 시각은 최종 원인이 밝혀진 수요일이 아니라, 이용자 제보로 사고 가능성을 처음 알게 된 화요일 오전 9시입니다. 회사는 확인된 내용만으로 1차 신고하고, 계정 생성 경로와 피해 범위는 조사 후 보완할 수 있었습니다.

교훈은 단순합니다. “확정되지 않았다”는 말은 신고를 멈추는 이유가 아니라, 확인된 사실과 추정 내용을 구분해 적어야 한다는 신호입니다.

복구보다 먼저 지켜야 할 디지털 흔적이 있습니다

사고 직후에는 서비스를 빨리 되살리고 싶은 마음이 앞섭니다. 그러나 서버 초기화, 악성파일 삭제, 로그 정리부터 하면 공격 경로와 개인정보 유출 범위를 확인할 자료가 사라질 수 있습니다.

개인정보 포털도 해킹 유출사고에서 시스템 포맷, 웹셸과 사건 자료의 무보존 삭제, 보안로그 미보존을 잘못된 조치로 안내합니다. 네트워크 분리, 원본 형태의 보존·백업, 가상서버 스냅샷, 로그 별도 백업을 먼저 검토해야 합니다. :contentReference[oaicite:4]{index=4}

감염 장비는 끄기 전에 상황을 구분합니다

일반 직원용 컴퓨터와 운영 서버는 대응 방식이 다를 수 있습니다. 메모리에서만 확인할 수 있는 악성행위가 의심되거나 서버 가용성이 중요한 경우에는 임의로 전원을 끄기보다 보안 담당자나 포렌식 전문가의 지시에 따라야 합니다.

랜섬웨어 감염 컴퓨터의 전원 종료 여부는 감염 범위와 암호화 진행 상태에 따라 판단해야 합니다. 급한 상황이라면 랜섬웨어 감염 컴퓨터 전원 종료 판단 기준도 함께 확인하세요.

최소 보존 목록을 별도 저장소에 복사합니다

• 웹서버와 응용프로그램 접근기록
• 방화벽, 침입방지장비, 웹방화벽 기록
• 가상사설망과 원격접속 기록
• 클라우드 감사기록과 관리자 활동기록
• 운영체제 보안·시스템·인증 기록
• 변조 또는 의심 파일의 원본 사본과 해시값
• 계정 생성·권한 변경·다중인증 변경 이력
• 데이터베이스 조회·내보내기·대량 내려받기 기록
• 보안관제 경보와 이용자 제보 원문
• 격리, 차단, 비밀번호 교체 등 조치 시각

공격자 계정은 차단하되 삭제 전에 기록합니다

비인가 계정을 발견했다면 우선 로그인과 토큰을 차단해야 합니다. 다만 계정 이름, 생성 시각, 생성 주체, 권한, 접속 주소, 실행 명령을 기록하지 않고 삭제하면 공격자의 이동 경로를 놓칠 수 있습니다.

신고서는 완벽한 보고서가 아니라 현재 상황표입니다

KISA 침해사고 신고 절차는 사고 유형, 기업과 신고자 정보, 사고 현황, 대응 현황 등을 작성한 뒤 사실 확인을 거쳐 접수가 완료되는 구조입니다. 법령상 서면, 전자우편, 전화, 인터넷 홈페이지 입력 등의 방식이 가능하지만, 어떤 방법을 선택하든 접수번호와 제출 내용을 보관하는 것이 안전합니다. :contentReference[oaicite:5]{index=5}

신고 전 한 장에 적어야 할 항목

기록 항목	작성 방법	예시
최초 인지 시각	날짜, 시각, 시간대, 발견 경로를 함께 기록	7월 14일 09:20, 고객센터 제보
추정 발생 시각	로그에서 확인된 최초 이상 시각	7월 13일 23:41 추정
사고 유형	확정과 추정을 구분	관리자 계정 탈취 의심
영향 시스템	서버·계정·서비스 단위로 작성	쇼핑몰 운영서버 1대, 관리자 계정 2개
피해 내용	확인된 사실만 우선 기록	상품 페이지 변조, 주문정보 유출 여부 조사 중
대응 현황	조치 시각과 담당자를 함께 기록	10:05 계정 잠금, 10:20 외부 접속 차단
개인정보 관련성	접근 가능성과 실제 유출을 분리	회원 DB 접근 흔적 확인 중
연락 담당자	즉시 연락 가능한 실무자 지정	보안담당자, 개인정보보호책임자

확인된 사실·추정·조사 중을 나누어 씁니다

신고서를 그럴듯하게 완성하려고 추정을 사실처럼 쓰면 나중에 설명이 꼬일 수 있습니다. “외부 전송 확인”, “외부 전송 의심”, “외부 전송 여부 조사 중”은 전혀 다른 표현입니다.

• 확인: 로그, 파일, 화면, 거래내역 등으로 검증된 내용
• 추정: 여러 정황상 가능성이 높지만 추가 확인이 필요한 내용
• 조사 중: 자료를 확보했으나 아직 판단하지 못한 내용
• 미확인: 관련 기록이 없거나 보존기간 만료로 확인이 어려운 내용

상담 완료와 신고 접수 완료를 구분합니다

118에 전화를 걸어 대응 방법을 들었다고 해서 법정 신고가 자동으로 완료됐다고 단정해서는 안 됩니다. 전화 과정에서 정식 신고가 접수됐는지, 별도의 신고 페이지 입력이 필요한지, 접수번호가 발급됐는지 확인하세요.

신고 후에는 제출 화면, 접수번호, 상담 시각, 담당자 안내, 추가 제출 자료를 한 폴더에 보관합니다. 사고 대응 기록은 나중에 고객, 보험사, 거래처, 감독기관에 조치 과정을 설명할 때도 쓰입니다.

개인정보 유출이 겹치면 신고 시계가 두 개가 됩니다

해킹으로 회원정보나 고객정보가 유출됐다면 침해사고 신고와 개인정보 유출신고를 각각 검토해야 합니다. 개인정보 포털도 해킹에 의한 개인정보 유출사고는 과학기술정보통신부 또는 KISA에 침해사고 신고를 별도로 해야 한다고 안내합니다. :contentReference[oaicite:6]{index=6}

24시간과 72시간을 하나로 합치지 마세요

침해사고 신고는 사고 발생을 알게 된 때부터 24시간이 기준입니다. 개인정보 유출신고는 유출 사실을 알게 된 후 72시간 이내가 기준이며, 다음 중 하나에 해당하면 신고 대상이 됩니다.

• 1천명 이상의 정보주체에 관한 개인정보가 유출된 경우
• 민감정보 또는 고유식별정보가 유출된 경우
• 개인정보처리시스템이나 개인정보 처리 기기에 대한 외부의 불법 접근으로 개인정보가 유출된 경우

구체적인 유출 항목이나 규모가 아직 확인되지 않았다면 현재까지 확인된 내용으로 우선 신고하고, 추가 내용은 확인되는 즉시 보완할 수 있습니다. 개인정보 보호법 시행령은 2026년 5월 19일 시행본에서 이 기준을 두고 있습니다. :contentReference[oaicite:7]{index=7}

불법 접근과 실제 유출을 구분해 조사합니다

개인정보처리시스템에 공격자가 들어왔다는 사실만으로 모든 개인정보가 외부에 전송됐다고 단정할 수는 없습니다. 반대로 외부 전송 로그가 없다는 이유만으로 유출 가능성이 없다고 단정하는 것도 위험합니다.

누가 어떤 계정으로 접속했는지, 조회와 내려받기 기능을 사용했는지, 데이터베이스 덤프가 생성됐는지, 비정상적인 대량 조회가 있었는지를 확인해야 합니다. 구체적인 조사 항목은 고객정보 유출 시 확인해야 할 로그를 참고할 수 있습니다.

기관 신고와 고객 통지는 별도 업무입니다

개인정보 유출신고는 감독기관에 사고 사실을 알리는 절차이고, 고객 안내문은 정보주체에게 피해 가능성과 대응 방법을 알려주는 절차입니다. 신고서를 제출했다고 고객 통지가 자동으로 끝나는 것은 아닙니다.

고객 안내문에는 확인되지 않은 원인을 단정하거나 책임을 회피하는 표현을 넣지 않는 것이 좋습니다. 통지 내용과 구성은 개인정보 유출 고객 안내문 작성법에서 별도로 확인할 수 있습니다.

직접 대응과 전문가 지원은 사고 규모로 나누지 않습니다

직원이 적은 회사라고 반드시 유료 대응업체가 필요한 것은 아닙니다. 반대로 서버 한 대만 감염됐다고 직접 해결해도 안전한 것도 아닙니다. 전문가 비용을 결정하는 핵심은 장비 수보다 침해 범위의 불확실성, 개인정보 관련성, 공격자의 지속 접속 가능성입니다.

내부 대응으로 시작해도 되는 경우

• 영향받은 시스템과 계정을 명확히 식별할 수 있는 경우
• 로그와 백업이 충분히 보존돼 있는 경우
• 공격자 접속을 차단했고 추가 확산 정황이 없는 경우
• 개인정보나 핵심 영업정보 접근 가능성이 낮은 경우
• 내부에 서버·클라우드·보안 기록을 분석할 담당자가 있는 경우

초기에 전문가를 부르는 편이 나은 경우

• 공격자가 아직 내부 시스템에 접속 중인 정황이 있는 경우
• 랜섬웨어가 백업, 가상화 서버, 여러 사업장으로 퍼진 경우
• 웹셸이나 백도어를 삭제해도 반복해서 나타나는 경우
• 개인정보 유출 범위와 정보주체 수를 산정하기 어려운 경우
• 금융·통신·의료·공공 등 별도 감독 규제가 적용되는 경우
• 고객·거래처·보험사와 손해배상 분쟁이 예상되는 경우
• 로그가 부족하거나 공격 발생 후 오랜 시간이 지난 경우

무료·부분 지원·종합 대응 비교표

대응 방식	적합한 상황	확인할 내용	주의점
내부 직접 대응	범위가 제한적이고 내부 역량이 충분함	로그 보존, 계정 차단, 신고 담당자 지정	자체 판단으로 증거를 삭제하지 않기
단기 기술 자문	특정 서버·로그 분석만 지원이 필요함	업무 범위, 결과물, 긴급 대응 가능시간	복구만 하고 원인 분석을 제외하는 계약 주의
포렌식·사고 대응	공격 범위와 유출 여부가 불명확함	증거 수집 방식, 보고서 수준, 신고 지원	초기 견적보다 대상 시스템이 늘어날 수 있음
법률·개인정보 자문 병행	신고·통지·계약 분쟁이 예상됨	적용 법령, 통지문 검토, 보험 통지기한	기술 조사 없이 법률 판단만 진행하지 않기

견적을 받을 때 물어볼 질문

1. 초기 분석 비용에 포함되는 서버, 계정, 저장공간의 범위는 어디까지인가요?
2. 원인 분석과 서비스 복구가 각각 포함돼 있나요?
3. 디스크 이미지, 로그, 악성파일을 어떤 방식으로 보존하나요?
4. 개인정보 유출 가능성 분석과 정보주체 수 산정도 지원하나요?
5. KISA 침해사고 신고와 개인정보 유출신고 자료 작성 지원이 포함되나요?
6. 결과물은 구두 설명, 요약 보고서, 상세 포렌식 보고서 중 어떤 형태인가요?
7. 야간·주말 긴급 대응과 추가 장비 분석 비용은 어떻게 계산하나요?
8. 재감염 확인과 복구 후 보안 점검은 별도 비용인가요?

개인정보 유출 대응업체의 비용은 조사 범위와 보고서 수준에 따라 차이가 큽니다. 견적을 비교해야 한다면 개인정보 유출 대응업체 비용과 계약 전 질문을 참고해 복구비와 조사비가 어떻게 나뉘는지 확인하세요.

자주 묻는 질문

개인 PC가 랜섬웨어에 감염돼도 KISA에 신고해야 하나요?

개인은 정보통신서비스 제공자에게 적용되는 법정 침해사고 신고 의무와는 구분되지만, 118에서 긴급상담과 대응 경로 안내를 받을 수 있습니다. 업무용 컴퓨터이거나 회사망과 연결돼 있었다면 개인 장비 문제로만 보지 말고 회사 보안 담당자에게 즉시 알리세요.

쇼핑몰이 10분간 디도스 공격을 받았지만 복구됐다면 신고 대상인가요?

장애 시간이 짧다는 이유만으로 신고 대상에서 자동 제외되지는 않습니다. 공격 트래픽이 실제로 확인됐는지, 정보통신서비스 제공자에 해당하는지, 추가 공격이나 다른 침해 흔적이 있는지를 검토해야 합니다. 최초 인지 시각을 먼저 기록한 뒤 KISA에 신고 필요성을 확인하는 편이 안전합니다.

사고 원인이 확정되지 않아도 24시간 내 신고해야 하나요?

네. 원인과 피해 규모를 모두 확정한 뒤 신고하는 구조가 아닙니다. 현재까지 확인된 발생 시각, 추정 원인, 피해 내용, 대응 현황과 연락처로 우선 신고하고, 새로 확인된 사실은 보완 신고할 수 있습니다.

118에 전화하면 법정 신고가 완료되나요?

전화 과정에서 상담만 진행됐는지 정식 신고까지 접수됐는지 확인해야 합니다. 법령은 전화 신고 방식을 허용하지만, 일반적인 상담 통화가 곧바로 정식 접수로 처리됐다고 단정해서는 안 됩니다. 접수번호, 접수완료 상태, 추가 제출 요청을 확인하세요.

클라우드 관리자 계정 탈취도 침해사고인가요?

비인가 사용자가 관리자 계정으로 접속해 설정, 데이터, 인증수단을 열람하거나 변경했다면 침해사고 가능성이 높습니다. 클라우드 감사기록, 접근키 사용내역, 새 계정 생성, 저장자료 내려받기와 외부 공유 설정 변경을 확인해야 합니다.

개인정보가 유출되지 않았어도 신고해야 하나요?

개인정보 유출 여부와 침해사고 여부는 같은 질문이 아닙니다. 디도스, 악성코드 감염, 웹셸 설치, 인증 우회처럼 개인정보 유출이 확인되지 않은 사고도 침해사고 신고 검토 대상이 될 수 있습니다.

외주 개발사나 호스팅사가 신고하면 우리 회사는 안 해도 되나요?

외주업체가 누구의 명의로 어떤 범위를 신고했는지 확인하기 전에는 자사의 의무가 끝났다고 단정하기 어렵습니다. 계약상 신고 책임, 사고가 발생한 시스템의 운영 주체, 접수 내용과 접수번호를 확인하고 필요한 경우 자사 명의의 추가 신고를 검토하세요.

랜섬웨어 공격자와 몸값 협상을 시작해도 되나요?

담당 직원이 개인적으로 협상하거나 회사 계정으로 즉시 송금하는 것은 피해야 합니다. 복호화 가능성, 데이터 유출 협박, 제재 대상 관련 위험, 사이버보험 통지 조건, 수사기관 신고, 재침투 가능성을 법률·보안 전문가와 함께 검토해야 합니다.

야간이나 주말에도 신고 준비를 해야 하나요?

24시간은 영업일 기준이 아니므로 주말이나 공휴일에도 계속 흐릅니다. KISA의 해킹·바이러스 긴급상담은 24시간 운영되지만, 상담 채널별 운영시간이 다를 수 있으므로 공식 안내를 확인하고 접수 증빙을 남겨야 합니다.

지금 15분 안에 사고 인지 기록표를 만드세요

지금 사고를 의심하고 있다면 새 문서 한 장을 열고 아래 여덟 항목부터 적으세요. 조사 결론을 기다리지 말고, 모르는 내용은 “조사 중”이라고 표시하면 됩니다.

1. 사고 가능성을 처음 알게 된 날짜와 시각
2. 경보, 직원 보고, 이용자 제보 등 발견 경로
3. 영향받았거나 영향을 받았을 가능성이 있는 시스템
4. 확인된 공격 유형과 아직 추정 중인 공격 유형
5. 현재까지 확인된 서비스·정보·금전 피해
6. 개인정보처리시스템 접근 가능성과 유출 여부
7. 이미 수행한 격리·차단·계정 보호 조치와 시각
8. KISA 및 관계기관과 연락할 담당자와 전화번호

그다음 최초 인지 시각에서 24시간 뒤를 표시하고, 신고 담당자와 접수 확인 담당자를 따로 지정하세요. 같은 사람이 모든 일을 맡더라도 역할을 문서에 나누어 적으면 “전화는 했지만 접수번호는 없는” 빈틈을 줄일 수 있습니다.

최종 검토: 2026-07