ISMS-P 준비, 스타트업 개발팀은 언제 무엇부터 할까

결론부터 말하면 국내 스타트업 대부분은 2026년 10월 현재 ISMS-P 인증 의무 대상이 아닙니다. 지금 법적으로 인증을 받아야 하는 쪽은 정보통신망법에 따른 ISMS 의무 대상자입니다. 정보통신서비스 부문 전년도 매출 100억 원 이상이거나, 전년도 말 기준 직전 3개월 일평균 이용자가 100만 명 이상인 사업자 등이 여기에 들어갑니다. 이들도 ISMS와 ISMS-P 중 하나를 골라 받을 수 있습니다. 2026년 개정 개인정보 보호법으로 ISMS-P 의무화 근거가 생기긴 했습니다. 하지만 누가 대상인지 정하는 시행령 조항은 9월 11일 시행된 최종 시행령에서 빠졌고, 입법예고안의 기준도 매출 1조 원 이상 같은 대형 사업자를 겨냥한 것이었습니다.

그래도 준비를 미룰 일은 아닙니다. 매출이 100억 원에 가까워지거나, B2B 고객사가 인증서를 요구하거나, 투자 실사에서 보안 체계를 물으면 그때부터 짧게 잡아도 반년 넘게 걸립니다. 심사에서 시간을 가장 많이 잡아먹는 건 정책 문서가 아닙니다. 접근통제, 로그, 개발·운영 환경 분리, 변경관리 같은 기술 항목의 운영 증적입니다. 이 글에서는 인증 컨설팅 관점이 아니라 개발팀 관점에서, 지금 코드와 인프라에 무엇을 어떤 순서로 넣어 두면 나중에 다시 만들지 않아도 되는지 정리합니다.

인증서 없이 고객사 보안 점검부터 받는 단계라면 고객사 보안 점검 대응 가이드를 같이 보면 좋습니다. 질문 항목이 ISMS-P 기준과 상당 부분 겹칩니다.

우리 회사는 의무 대상일까: 2026년 10월 기준 판단법

판단할 축은 두 가지입니다. 정보통신망법상 ISMS 의무(현행)와 개인정보 보호법상 ISMS-P 의무(도입 중)입니다.

1) 현행 ISMS 의무 대상 (정보통신망법)

정보통신서비스 부문 전년도 매출 100억 원 이상
전년도 말 기준 직전 3개월 일평균 이용자 100만 명 이상
그 밖에 ISP, IDC, 일정 규모 이상의 상급종합병원·대학 등

여기서 매출은 회사 전체 매출이 아니라 정보통신서비스 부문 매출입니다. 오프라인 매출 비중이 큰 회사라면 회계팀과 부문을 어떻게 나눌지 먼저 정리해야 합니다.

2) ISMS-P 의무화 (개인정보 보호법 개정)

개정법은 2026년 3월 공포, 9월 11일 시행됐습니다.
6월 입법예고안에는 의무 대상으로 공공시스템운영기관 일부, 이동통신사업자, 본인확인기관, 그리고 전년도 매출 1조 원 이상이면서 정보통신서비스 부문 매출 100억 원 이상이고 국내 정보주체가 일평균 3,000만 명 이상인 사업자가 들어 있었습니다. 인증 기한은 2028년 12월 31일이었습니다.
다만 이 대상 범위 조항은 최종 시행령에서 빠졌고, 후속 개정으로 다시 정해질 예정입니다.

정리하면 이렇습니다.

[판단 순서]
1. 정보통신서비스 부문 매출 ≥ 100억 원 또는 일평균 이용자 ≥ 100만 명?
   → 예: ISMS 의무 대상. 다음 해 인증 일정을 바로 잡는다 (ISMS-P 선택 가능)
2. 아니오인데 1~2년 안에 넘을 것 같다?
   → 지금부터 기술 항목 증적을 쌓는다 (이 글의 순서)
3. B2B 고객사·투자사·공공 입찰에서 인증서를 요구받는다?
   → 의무가 아니어도 사실상 필요. 간편인증 해당 여부를 확인한다
4. 모두 아니다
   → 인증보다 개인정보 안전성 확보조치 기준 준수가 먼저다

4번에 해당하더라도 개인정보를 처리한다면 안전성 확보조치 기준은 지금도 적용됩니다. 개발자가 구현할 항목은 개인정보 안전성 확보조치 기준, 개발자가 구현할 항목에 따로 정리해 두었습니다. ISMS-P 기술 항목과 많이 겹치므로 여기서부터 시작하면 손해 볼 일이 없습니다.

기간과 비용은 어느 정도 드나

2024년 7월 중소기업 간편인증 도입 당시 보도에 따르면 ISMS-P 심사 수수료는 기존 1,000만~~1,800만 원 수준이었습니다. 간편인증 대상이 되면 600만~~1,100만 원 수준으로 내려갑니다. 간편인증은 정보통신서비스 매출 300억 원 미만 중소기업 등이 대상입니다. 금융회사, 가상자산사업자 같은 일부 업종은 빠집니다. 수수료는 심사 범위에 따라 달라지므로 실제 금액은 KISA 안내로 확인하세요.

실제 비용은 수수료보다 다음 항목에서 더 커집니다.

컨설팅 비용(쓰는 경우)
접근제어·DB 접근통제 등 솔루션 도입 비용
개발팀의 구조 변경 공수: 계정 분리, 로그 체계, 배포 파이프라인 수정

기간은 경험상 "기술 기반이 어느 정도 있는 회사"가 6개월 안팎, 아무것도 없는 회사는 1년 가까이 걸립니다. 심사는 문서가 있느냐보다 그 문서대로 일정 기간 운영했느냐를 봅니다. 로그 점검 기록, 권한 검토 기록, 변경 승인 기록이 몇 달 치 쌓여 있어야 합니다. 그래서 기술 항목은 인증을 결정하기 전에 미리 돌려 두는 편이 일정상 훨씬 유리합니다.

1순위: 계정과 권한, 운영 접근부터 분리한다

현행 인증 기준에서 2.5(인증 및 권한관리)와 2.6(접근통제)에 해당합니다. 초기 스타트업에서 가장 흔한 상태는 클라우드 루트 계정이나 관리자 계정 하나를 여럿이 같이 쓰고, 개발자 전원이 운영 DB에 직접 붙을 수 있는 구조입니다. 심사에서는 "누가 접근했는지 개인 단위로 식별되는가", "권한이 직무에 맞게 최소로 부여됐는가", "주기적으로 검토하는가"를 묻습니다.

서비스 코드 안의 관리자 기능도 같은 기준으로 봅니다.

// 취약한 예: 로그인만 되어 있으면 누구나 회원 정보를 내려받을 수 있다
app.get('/admin/users/export', requireLogin, async (req, res) => {
  const users = await db.user.findMany();
  res.json(users);
});

// 개선한 예: 역할 기반 권한 + 개인 식별 가능한 감사 로그 + 필요한 필드만
app.get('/admin/users/export',
  requireLogin,
  requireRole('privacy_admin'),
  async (req, res) => {
    const users = await db.user.findMany({
      select: { id: true, email: true, createdAt: true },
    });
    await audit.write({
      actorId: req.user.id,
      action: 'USER_EXPORT',
      target: 'users',
      count: users.length,
      ip: req.ip,
      reason: req.query.reason ?? null,
    });
    res.json(users);
  });

인프라 쪽 체크리스트는 다음과 같습니다.

클라우드 루트 계정은 잠그고 MFA를 건다. 일상 작업은 개인 IAM 사용자나 SSO로 한다
운영 DB는 사설망에 두고 접근 경로를 배스천이나 DB 접근제어 한 곳으로 모은다
공용 계정(admin, deploy)이 남아 있다면 사용자와 용도를 문서로 정하고, 가능하면 개인 계정으로 바꾼다
퇴사·직무 변경 때 권한 회수 절차를 정하고, 분기마다 권한 검토 결과를 남긴다
관리자 페이지는 IP 제한이나 추가 인증을 건다. 세부 항목은 관리자 페이지 보안 체크리스트 참고

2순위: 로그는 '많이'가 아니라 '누가 무엇을'

2.9.4(로그 및 접속기록 관리)와 2.9.5(로그 및 접속기록 점검)입니다. 개발팀이 자주 놓치는 부분은 애플리케이션 디버그 로그와 개인정보처리시스템 접속기록을 구분하지 않는 것입니다. 심사에서 보는 쪽은 후자입니다. 누가(계정), 언제, 어디서(IP), 어떤 정보주체의 정보를, 무엇을 했는지(조회·수정·다운로드)가 남아야 합니다. 그리고 이 기록을 정기적으로 점검한 흔적이 있어야 합니다.

# 취약한 예: 요청 본문을 통째로 남겨 비밀번호·주민번호가 로그에 섞이고,
# 정작 "누가 누구를 조회했는지"는 남지 않는다
logger.info(f"request body: {request.json}")

# 개선한 예: 접속기록은 별도 스트림, 필드 고정, 민감값은 남기지 않음
def write_access_record(actor, action, subject_id, request):
    access_logger.info(
        "personal_data_access",
        extra={
            "actor_id": actor.id,
            "action": action,             # READ / UPDATE / EXPORT
            "subject_id": subject_id,     # 정보주체 식별자(내부 ID)
            "client_ip": request.remote_addr,
            "occurred_at": utc_now_iso(),
        },
    )

구현할 때 확인할 것:

접속기록은 앱 서버 로컬 파일이 아니라 수정·삭제 권한이 분리된 저장소(별도 버킷, 로그 서비스)로 보낸다
보관 기간은 안전성 확보조치 기준과 사내 정책에 맞춘다. 처리 규모나 고유식별·민감정보 여부에 따라 기준이 달라지니 직접 확인한다
월 1회처럼 점검 주기를 정하고, 대량 조회·업무시간 외 다운로드 같은 조건으로 점검한 결과를 기록한다
2.9.6(시간 동기화) 때문에 서버·DB·로그 수집기 시간이 NTP로 맞춰져 있는지도 본다

3순위: 개발·운영 환경 분리와 시험 데이터

2.8.3(시험과 운영 환경 분리)과 2.8.4(시험 데이터 보안)입니다. 원칙은 개발·시험 시스템을 운영과 분리하고, 개발자가 운영에 불필요하게 접근하지 못하게 하는 것입니다. 소규모 팀이라 완전히 분리하기 어렵다면 상호 검토, 변경 승인, 모니터링 같은 보완 통제를 두고 그 근거를 남겨야 합니다.

흔한 결함은 "스테이징에 운영 DB 덤프를 그대로 복원해서 쓰는" 경우입니다.

# 취약한 예: 운영 데이터를 그대로 스테이징에 복원
pg_dump "$PROD_DATABASE_URL" | psql "$STAGING_DATABASE_URL"

-- 개선한 예: 꼭 운영 데이터 기반이 필요하면 별도 격리 환경에서 비식별 처리 후 이관
UPDATE users SET
  email = 'user' || id || '@example.com',
  phone = NULL,
  name  = '테스트' || id,
  birth_date = NULL;
-- 처리 일시, 담당자, 대상 테이블을 시험 데이터 관리 대장에 기록

이 단계의 체크리스트:

운영과 개발·스테이징은 클라우드 계정(또는 프로젝트) 단위로 나눈다. 같은 VPC 안에서 보안그룹으로만 나누면 설명하기 어렵다
운영 비밀값(DB 비밀번호, API 키)은 개발 환경에서 읽을 수 없게 한다. 비밀값 관리는 API 키 유출 방지 체크리스트의 방식과 같다
시험 데이터는 가능하면 생성 데이터를 쓰고, 운영 데이터를 쓸 때는 승인·비식별·사용 후 삭제 기록을 남긴다

4순위: 변경관리와 배포를 파이프라인으로 강제한다

2.9.1(변경관리), 2.8.5(소스 프로그램 관리), 2.8.6(운영환경 이관)입니다. 심사에서는 "운영 반영 전에 누가 검토·승인했는가"와 "운영 반영 경로가 통제되는가"를 봅니다. 문서로 승인 절차를 만들고 엑셀로 기록하는 방식은 금방 무너집니다. 개발팀이라면 도구로 강제하고 기록은 자동으로 남기는 쪽이 현실적입니다.

# 개선한 예: GitHub Actions 운영 배포
# - main 브랜치 보호(PR 리뷰 필수, 직접 push 금지)는 저장소 설정에서
# - production environment에 승인자(required reviewers)를 지정
name: deploy-production
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # 승인 후에만 실행, 승인 기록이 남는다
    permissions:
      id-token: write          # 장기 키 대신 OIDC로 클라우드 인증
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

반대로 개발자 노트북에서 운영 서버로 SSH 접속해 git pull과 재시작을 하는 방식은 승인도, 이관 기록도 남지 않습니다. 확인할 것:

운영 배포 권한을 가진 사람을 최소화하고, 긴급 배포 절차(사후 승인)를 따로 정한다
인프라 변경도 Terraform 같은 코드로 관리해 PR 리뷰를 거치게 하면 변경 이력이 그대로 증적이 된다
운영 콘솔에서 직접 바꾼 설정은 정기적으로 코드와의 차이를 점검한다

지금부터 6개월 로드맵

의무 대상이 아니어도 아래 순서로 진행하면, 인증을 결정할 때 기술 항목 증적이 이미 몇 달 치 쌓여 있게 됩니다.

1개월차: 자산 목록(서버, DB, SaaS, 개인정보 흐름) 작성. 루트 계정 잠금과 MFA, 공용 계정 정리
2개월차: 운영·개발 계정 분리, 운영 DB 접근 경로 일원화, 비밀값 관리 도구 도입
3개월차: 개인정보 접속기록 스키마 확정과 별도 저장소 적재, 첫 월간 점검 기록
4개월차: 브랜치 보호와 배포 승인, 인프라 코드화. 긴급 변경 절차 문서화
5개월차: 시험 데이터 정책, 첫 분기 권한 검토 기록, 취약점 점검 1회
6개월차: 증적 묶음 정리. 간편인증 해당 여부와 인증 범위 결정

자주 묻는 질문

의무 대상이 아닌데 ISMS-P를 먼저 받아도 되나요?

됩니다. 의무 대상이 아니어도 자율적으로 인증을 신청할 수 있습니다. 다만 인증은 받은 뒤에도 매년 사후심사가 있습니다. 고객사·입찰 요구처럼 분명한 이유가 없다면, 먼저 기술 항목을 운영해 보고 그 다음에 결정해도 늦지 않습니다.

ISMS와 ISMS-P 중 무엇을 받아야 하나요?

ISMS-P는 ISMS에 개인정보 처리 단계별 요구사항이 더해진 인증입니다. 보도 기준으로 ISMS는 80개, ISMS-P는 101개 항목입니다. 개인정보를 많이 다루는 B2C 서비스이거나 고객사가 ISMS-P를 명시하면 ISMS-P가 맞습니다. 개발팀이 준비할 기술 항목은 둘 다 거의 같습니다.

개발자가 3~4명뿐이라 환경 분리와 직무 분리가 어렵습니다.

소규모 조직은 완전한 분리 대신 보완 통제를 인정받는 경우가 있습니다. PR 상호 리뷰, 배포 승인 기록, 운영 접근 로그 모니터링처럼 "분리 못 한 위험을 어떻게 줄였는지"를 증적으로 보여 줄 수 있게 만드는 것이 핵심입니다.

정리

2026년 10월 현재 법적 의무는 정보통신망법상 ISMS(매출 100억 원 또는 일평균 이용자 100만 명 기준)이고, 개인정보 보호법상 ISMS-P 의무 대상 범위는 아직 시행령으로 확정되지 않았습니다.
인증 준비에서 시간이 걸리는 건 문서가 아니라 몇 달 치 운영 증적입니다.
개발팀은 접근통제, 접속기록, 환경 분리, 변경관리 순서로 지금 코드와 인프라에 넣어 두면 나중에 다시 만들지 않아도 됩니다.
직접 점검이 어렵다면 무료 분석 신청으로 현재 상태를 한 번 진단받아 볼 수 있습니다.