---
type: knowledge
domain: product
role: Security·Privacy
status: active
last-reviewed: 2026-07-27
---

# Security·Privacy 기획 가이드

> Security·Privacy 기획은 자산과 신뢰 경계를 식별하고, 위험을 예방·탐지·대응·승인 가능한 통제로 바꾸는 작업이다. 외주 프로젝트에서는 여기에 하나가 더 붙는다 — **발주사 보안 정책 준수와 보안성 검토(심사) 통과**. 심사에서 지적되면 오픈이 밀린다.

## 책임과 두 가지 모드

- 구현자 모드: 인증·인가·세션·암호화 같은 보안 기능을 검증된 라이브러리로 구현한다.
- 리뷰어 모드: 다른 구현 역할의 실제 변경물을 독립적으로 점검한다.
- 입력: 요구사항, architecture·data flow, 역할별 Result Card, 개인정보 처리 목적, **발주사 보안 정책·가이드라인, 보안성 검토(심사) 점검 항목·일정**
- 범위 밖: 자체 암호·해시 알고리즘, 평문 secret·PII 기록, 근거 없는 위험 수용. 계약에 없는 보안 요구(추가 인증 수단, 별도 보안 솔루션 도입 등)는 거절이 아니라 CR 절차로 회부한다.
- 다음 소비자: Tech Lead, QA, Release 승인자, 발주사 보안 담당·업무 책임자

## 기획 순서

1. [[01_위협 모델]]에서 자산·행위자·trust boundary와 위협을 식별한다 — 발주사 심사 항목을 함께 대조한다.
2. [[02_인증·인가·세션 정책]]에서 default-deny 권한과 token 수명을 확정한다.
3. [[03_데이터 분류·보존 정책]]에서 수집·저장·공유·삭제의 수명과 종료 시 파기를 정한다.
4. [[04_보안 통제·테스트 계획]]에서 위험·심사 항목과 예방·탐지·테스트를 연결한다.
5. [[05_취약점·예외 승인대장]]에서 발견·심사 지적사항, Owner, 기한, 오픈 차단과 예외를 추적한다.
6. [[90_Security·Privacy 완료 체크리스트]]로 구현·리뷰 gate를 확인한다.
7. [[99_Security·Privacy Result Card 템플릿]]으로 모드별 결과를 분리 저장한다.

## 핵심 결정 원칙

- **발주사 보안 정책이 수행사 내부 표준보다 우선한다.** 충돌하면 임의 판단하지 말고 협의 결과를 기록한다.
- **보안성 검토 점검 항목은 착수 시 입수**해 통제 매핑에 포함한다 — 심사 직전 대응은 오픈 지연의 단골 원인이다.
- 모든 보호 자원은 명시적 인가를 요구하며 client의 권한 주장을 신뢰하지 않는다.
- 암호·hash·token은 검증된 표준 라이브러리와 안전한 default를 사용한다.
- 상태 변경 요청에는 CSRF 방어, 민감 endpoint에는 rate limit을 둔다.
- 개인정보는 목적에 필요한 최소 범위만 수집하고 보존 기한 후 검증 가능하게 삭제한다 — 데이터의 소유자는 발주사다.
- CRITICAL·HIGH는 해소하거나 권한 있는 승인자(발주사 위험 수용 주체 포함)가 기간·보완 통제와 함께 수용해야 한다.
- 리뷰어 모드는 다른 리뷰 결론을 먼저 보지 않고 실제 변경물로 독립 판정한다.

## 완료된 기획의 조건

- 위험별 자산, 공격 경로, severity, 통제, 검증, Owner, 기한이 연결된다.
- 인증·인가 matrix와 session·cookie·CSRF·rate limit 정책이 구체적이고 발주사 계정·세션 정책과 정합한다.
- PII의 수집 근거, 저장 위치, 공유 대상, 보존·삭제 증거와 프로젝트 종료 시 수행사 보유 사본 파기 계획이 있다.
- 오픈·검수 차단 이슈와 예외 승인 범위·만료일이 명시되고, 보안성 검토 제출용 증적이 추출 가능하다.

## 함께 읽기

- [[00_역할별 기획 허브]]
- [[00_역할별 기획 운영 가이드]]
- [[역할별 개발 산출물]]
- [[외주 개발 산출물]] · [[SI 수주와 범위 관리]]
- [[05_보안 설계]] — 설계 판단 기준(03_설계 역할별)