국내 규제 대응 — ISMS-P, 개인정보 영향평가, 시큐어 코딩 가이드

개념

m41과의 경계 — m41의 금융권 QA 레슨은 금융 감독 체계 안에서의 심사 대응 을 다룬다. 이 레슨은 업종을 가리지 않는 일반 인증기준과 QA 증거의 생산 방법 이다. 같은 ISMS-P라도 금융회사가 받는 심사에는 전자금융감독규정 등이 겹쳐 얹히는데, 그 겹침은 m41에서 본다.

세 규제의 성격이 다르다

먼저 셋을 구분한다. 성격이 다르므로 QA가 붙는 지점도 다르다.

세 가지의 공통점이 하나 있다. 결론이 아니라 근거를 요구한다. "안전하게 관리하고 있습니다"는 답이 되지 않고, "누가 언제 무엇을 확인했고 그 기록이 어디 있다"가 답이 된다. QA 조직이 컴플라이언스에서 쓸모 있는 이유가 여기 있다 — 우리는 원래 그런 기록을 만드는 직군이다.

ISMS-P 인증기준의 구성

정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준은 세 영역으로 구성된다.

정보보호 관리체계(ISMS)만 받는 기관은 1·2영역의 80개 를 적용받고, 개인정보까지 포함한 ISMS-P는 3영역을 더해 101개 를 적용받는다. (영역·항목 수는 KISA·개인정보보호위원회의 「ISMS-P 인증기준 안내서」 기준이다. 개별 인증기준의 번호와 문구는 반드시 현행 안내서 원문 에서 확인한다.)

한 가지 주의. 2025~2026년에 인증제도 개편이 추진되고 있다 — 인증 등급 차등화, 강화 인증기준 추가, 심사 방식 변경 등이 발표됐고 단계적으로 시행된다고 알려져 있다. 개편의 구체적 내용과 시행 시점은 과학기술정보통신부·개인정보보호위원회의 고시와 KISA 공지에서 확인해야 한다. 사내 문서에 항목 수를 박아 두지 말고 출처와 확인일자를 함께 적는 습관 을 들인다.

QA가 증거를 대는 항목

101개 전부가 QA의 일이 아니다. QA가 실제로 증적을 만드는 곳은 크게 세 덩어리다. (아래 분야 이름은 이해를 위한 요약이며, 정확한 인증기준 번호는 안내서 원문 확인.)

① 정보시스템 도입·개발 단계의 보안 — 시험 증적

"보안 요구사항을 정의했고, 개발 중 보안을 적용했고, 시험으로 확인했고, 결과를 반영했다"는 흐름을 증명해야 한다. QA가 내놓는 것.

마지막 줄이 실무에서 가장 자주 지적된다. 개발·시험 환경에서 운영 데이터를 쓰는 관행 은 국내 심사에서 거의 반드시 확인하는 항목이다. 가명·합성 데이터를 쓰거나, 불가피하게 실데이터를 쓴다면 승인·통제·파기 기록이 있어야 한다.

② 변경관리 — 변경 기록

"변경이 승인되고, 영향이 검토되고, 시험되고, 되돌릴 수 있었다"를 증명한다.

• 변경 요청과 승인 기록(누가 승인했는가)
• 영향 범위 분석 — 회귀 테스트 범위를 어떻게 정했는가가 곧 영향 분석 증적이다
• 시험 결과와 배포 승인
• 롤백 계획과 실제 롤백 이력
• 긴급 변경의 사후 승인 기록 — 예외 절차가 문서화돼 있고 실제로 따랐는지 를 본다

CI/CD가 있는 조직이라면 이 증적의 대부분이 이미 파이프라인에 있다. 문제는 심사에서 볼 수 있는 형태로 꺼내지 못하는 것 이다. 머지 요청에 승인자·연결된 이슈·테스트 통과 기록이 남게 설정해 두면, 캡처 몇 장으로 끝나는 일이 된다.

③ 취약점 점검과 조치 — 조치 확인서

"정기적으로 점검하고, 발견을 조치하고, 조치를 확인했다"는 세 번째 단계가 자주 빈다. 조치 확인서에 들어가는 것.

점검 대상        시스템·범위·점검일
점검 방법        도구/수동, 점검 기준(가이드·체크리스트 명)
발견 사항        항목별 등급, 재현 절차 위치
조치 내용        변경 내역과 배포 시점
확인 결과        재검증 수행자·일시·판정(통과/미통과)
잔여 항목        예외 승인 문서 번호와 재검토 기한

레슨 5에서 만든 재검증 계획과 예외 승인 문서가 그대로 이 양식의 재료가 된다. 따로 만들지 않는다 는 것이 요령이다 — 평소 산출물이 증적이 되게 형식을 맞춰 둔다.

개인정보 영향평가(PIA)

대상

개인정보 보호법 제33조 제1항과 시행령 제35조에 따라, 공공기관 이 아래에 해당하는 개인정보파일을 구축·운용·변경하려면 영향평가를 해야 한다.

민간 사업자는 법상 의무 대상이 아니지만, 자율적으로 수행하는 것이 권장 되며 대규모 개인정보를 다루는 서비스는 사실상 같은 절차를 내부 기준으로 운영하는 곳이 많다. (대상 기준의 정확한 문구와 최신 개정 여부는 국가법령정보센터의 시행령 원문에서 확인한다.)

절차와 QA의 기여

절차는 대체로 사전 준비 → 영향평가 수행 → 이행 점검 의 세 구간이다. 공공기관은 지정된 평가기관에 의뢰하고 결과를 제출한다. QA가 기여하는 지점이 분명한 것은 다음 네 가지다.

1. 개인정보 흐름 검증 — 흐름표·흐름도에 적힌 수집→저장→이용→제공→파기 경로가 실제 시스템과 일치하는지 확인한다. 이건 QA가 가장 잘하는 일이다. 문서에는 없는 로그 적재, 분석 도구 전송, 캐시 잔존, 백업 사본이 여기서 드러난다
2. 안전성 확보조치의 동작 확인 — 접근권한 관리, 암호화, 접속기록 보관, 화면 마스킹 같은 통제가 선언이 아니라 실제로 동작하는지 케이스로 확인한다
3. 파기의 실증 — 보유기간 경과 데이터가 실제로 지워지는지. 화면에서 안 보이는 것과 DB에서 사라진 것은 다르다. 백업·로그·데이터 웨어하우스 사본까지 본다
4. 개선과제 재검증 — 영향평가 결과로 나온 개선과제는 레슨 5의 재검증 절차와 동일하게 다룬다. 이행 점검 시점에 "조치했다"가 아니라 "확인했다"가 필요하다

특히 3번이 QA가 없으면 잘 안 된다. 삭제 기능의 테스트 케이스가 "삭제 후 목록에서 사라짐"으로 끝나 있으면 그 통제는 검증된 것이 아니다.

소프트웨어 개발보안(시큐어 코딩) 점검

근거와 문서

행정·공공기관의 정보시스템 사업에는 소프트웨어 보안약점을 제거한 상태로 개발 할 의무가 붙는다. 근거는 「전자정부법」 제45조 제3항과 그에 따른 행정안전부의 「행정기관 및 공공기관 정보시스템 구축·운영 지침」이고, 제거해야 할 보안약점 목록은 그 지침의 별표 에 있다. 감리에서도 보안약점 제거 여부가 검사항목에 포함된다.

실무에서 참조하는 문서는 두 종이다.

두 문서는 개정되며 보안약점의 유형 수와 분류가 판본마다 달라진다. 사내 체크리스트에는 항목 수를 적지 말고 "OO년 OO월판 기준" 과 확인일자를 적는다. 민간 서비스도 이 가이드를 리뷰 체크리스트의 뼈대로 쓰는 것이 유리하다 — 국내 감리·발주·인증에서 공통 언어가 되기 때문이다.

개발·시험 단계에 붙이는 법

가이드를 문서로만 두면 아무 일도 일어나지 않는다. 다섯 지점에 붙인다.

설계 리뷰    보안 요구사항 목록을 설계 산출물 검토 항목에 포함
코드 리뷰    가이드 유형 중 이 프로젝트에 해당하는 것만 추린 체크리스트
CI 게이트    SAST 규칙을 가이드 유형에 매핑, 신규 코드 기준으로 차단
기능 시험    입력 검증·인가·오류 처리 항목을 테스트 케이스로 (레슨 2·3)
진단·검수    진단가이드 기준의 점검과 조치 확인서

두 가지 실무 요령이 있다.

첫째, 전체 유형을 다 넣지 않는다. 언어·프레임워크에 해당 없는 유형(예: 특정 네이티브 메모리 약점)을 리뷰 체크리스트에 남기면 체크리스트가 형식이 된다. 프로젝트 스택에 맞게 추려 20개 이하로 만들고, 제외한 유형과 제외 사유를 별지에 남긴다. 제외 사유가 곧 심사 대응 문서 다.

둘째, 신규 코드 기준(new code gate) 으로 시작한다. 레거시 전체를 기준선으로 잡으면 수천 건이 뜨고 아무도 보지 않는다. "이번 변경에서 새로 생긴 약점은 0건"을 게이트로 걸고, 레거시는 별도 부채 항목으로 기한을 붙여 줄인다. m23의 스캔 리포트 분류 레슨과 같은 원리다.

세 규제를 하나의 흐름으로

설계        보안 요구사항 정의 ─┬─ ISMS-P: 요구사항 정의 증적
                              └─ PIA: 개인정보 흐름표 작성
개발        시큐어 코딩 + 코드 리뷰 ── 개발보안 가이드 체크리스트
CI          SAST/SCA 게이트 ── 신규 코드 기준, 예외는 티켓으로
시험        보안 테스트 케이스 실행 ── ISMS-P: 시험 증적
            개인정보 흐름·파기 검증 ── PIA: 흐름 일치 확인
배포        릴리스 게이트 승인 ── ISMS-P: 변경관리 증적
운영        정기 점검 → 조치 → 재검증 ── 조치 확인서 / PIA 이행 점검

이 그림에서 중요한 것은 왼쪽 열이 이미 하고 있는 일이라는 점 이다. 규제 대응은 새 작업을 추가하는 일이 아니라, 하고 있는 일의 기록 형식을 맞추는 일 이다.

실무에서 왜 필요한가

첫째, 증적이 없으면 통제가 있어도 없는 것으로 판정된다. 실제로 매 릴리스 보안 점검을 하고 있어도 기록이 개인 메모나 사라진 슬랙 스레드에 있으면 심사에서는 "미이행"이다.

둘째, 심사 직전에 몰아서 만들면 품질이 나쁘고 비용이 크다. 3개월치 시험 기록을 역산하는 조직을 실제로 본다. 그 시간이면 파이프라인에 기록이 남게 설정을 고칠 수 있다.

셋째, 발주·검수 조건이 된다. 공공·금융 사업은 개발보안 이행과 점검 결과가 검수 요건에 들어간다. QA가 그 확인을 맡는 경우가 많다.

넷째, 개인정보 관련 사고는 결과가 크다. 과징금·과태료와 별개로 서비스 신뢰에 타격이 온다. 흐름표와 실제의 불일치를 찾는 일은 사고 예방에서 비용 효율이 가장 높은 활동에 속한다.

실습 과제

모든 과제는 자사 산출물과 공개된 규제 원문 을 대상으로 한다.

과제 1 — 증적 갭 분석 (30분)

담당 서비스의 최근 릴리스 한 건을 골라, 본문 ①②③의 증적 표를 기준으로 실제로 존재하는 기록 을 찾아 아래 표를 채운다.

"꺼내는 데 걸리는 시간"이 10분을 넘는 항목은 사실상 없는 증적으로 본다. 그 항목에 대해 평소 산출물에서 자동으로 남게 하는 방법 을 한 줄씩 적는다. 마지막에 가장 비용이 적고 효과가 큰 개선 3개를 골라 순위를 매긴다.

과제 2 — 개인정보 흐름표와 실제 대조 (30분)

담당 기능 하나를 골라 개인정보 흐름표를 직접 그린다(수집 → 저장 → 이용 → 제공 → 파기). 그다음 실제 시스템에서 확인 해 문서에 없는 경로를 찾는다. 최소한 아래 여섯 곳을 본다.

• 애플리케이션 로그 / 접근 로그
• 분석·마케팅 SDK나 외부 전송
• 캐시·세션 저장소
• 백업과 복제본
• 데이터 웨어하우스·BI 사본
• 운영자 화면에서 조회 가능한 범위

발견한 불일치마다 "문서를 고칠 것"과 "시스템을 고칠 것"을 구분한다. 그리고 파기 검증 케이스를 저장 위치 전부에 대해 다시 설계한다.

과제 3 — 프로젝트용 개발보안 체크리스트 추리기 (25분)

「소프트웨어 개발보안 가이드」의 보안약점 유형 목록을 원문에서 확인하고, 담당 프로젝트의 언어·프레임워크에 해당하는 것만 추려 20개 이하의 코드 리뷰 체크리스트를 만든다. 각 항목에 ① 리뷰에서 볼 것, ② SAST 규칙으로 대체 가능한지, ③ 테스트 케이스로 확인 가능한지를 표시하고, 제외한 유형은 별지에 제외 사유 와 함께 남긴다.

자가 체크리스트

• ISMS-P 인증기준이 3개 영역 101개이고 ISMS는 2개 영역 80개임을 안다
• 인증기준 번호·문구는 현행 안내서 원문에서 확인한다는 원칙을 지킨다
• 시험 증적·변경관리 기록·조치 확인서를 평소 산출물에서 뽑아낼 수 있다
• 개발·시험 환경의 운영 데이터 사용 통제 기록을 준비할 수 있다
• 조치 확인서의 필수 항목 여섯 줄을 열거할 수 있다
• 개인정보 영향평가의 공공기관 의무 대상 기준(5만·50만·100만)을 말할 수 있다
• 개인정보 흐름표를 실제 시스템과 대조해 문서에 없는 경로를 찾을 수 있다
• 파기 검증을 백업·로그·사본까지 포함해 설계한다
• 개발보안 의무의 근거가 전자정부법과 행정안전부 지침임을 안다
• 개발보안 체크리스트를 프로젝트 스택에 맞게 추리고 제외 사유를 남긴다

흔한 실수

• 항목 수와 조문 번호를 기억으로 쓴다. 인증기준과 가이드는 개정된다. 출처와 확인일자를 함께 적지 않은 사내 문서는 1~2년이면 틀린 문서가 된다.
• 심사 직전에 증적을 만든다. 역산한 기록은 날짜가 어긋나고, 그 어긋남이 더 큰 지적이 된다.
• "자동화 테스트가 있으니 증적이 있다"고 생각한다. 실행 기록이 보존되고 조회 가능해야 증적이다. 로그가 7일 뒤 사라지는 CI는 증적을 남기지 않는다.
• 개발·시험 환경에 운영 데이터를 복사한다. 국내 심사에서 가장 자주 나오는 지적이고, 사고 시 피해 범위를 키운다.
• 삭제 검증을 화면 기준으로 끝낸다. 목록에서 사라진 것은 파기가 아니다. 저장 위치 전부를 봐야 한다.
• 영향평가를 평가기관에 전부 맡긴다. 흐름표가 실제와 다르면 평가 결과도 틀린다. 흐름 검증은 시스템을 아는 사람이 해야 한다.
• 개발보안 체크리스트에 전체 유형을 넣는다. 해당 없는 항목이 많으면 리뷰가 형식이 되고, 정작 중요한 항목이 묻힌다.
• 레거시 전체를 SAST 기준선으로 잡는다. 수천 건이 뜨고 아무도 보지 않는다. 신규 코드 기준으로 시작한다.
• 규제 대응을 QA 혼자 한다. 증적의 소유자는 각 활동의 담당자다. QA는 형식을 정하고 빠진 것을 지적한다.

참고 자료

• 개인정보보호위원회 — 인증제도(ISMS-P) — 제도 개요와 고시 안내
• 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서」(KISA·개인정보보호위원회) — 영역별 인증기준의 정본. 항목 번호·문구는 현행판 원문 확인
• 국가법령정보센터 — 개인정보 보호법 제33조, 시행령 제35조, 전자정부법 제45조 원문
• 개인정보보호 종합포털 — 영향평가 의무 대상 — 대상 판단 기준
• 행정안전부 — 소프트웨어 개발보안 가이드 · KISA 소프트웨어 개발보안 자료 — 가이드·진단가이드 최신판(판본과 유형 수는 원문 확인)
• 레슨 s5-m50-l05 — 침투 테스트 절차와 재검증·예외 승인 문서
• 레슨 s7-m23-l03 — 스캔 리포트 분류와 오탐 처리
• 레슨 s2-m41-l01 — 금융 IT 규제 개요(금융권 맥락)