12.2 체크리스트

이 체크리스트는 실용적이고 바로 쓸 수 있는 빠른 참조입니다. 어느 체크리스트든 풀 리퀘스트 템플릿, 위키 페이지, 티켓, 리뷰 회의 안건에 복사해 맥락에 맞게 항목을 조정하십시오. 각 항목을 사람이 확인하고 예 또는 아니오로 답할 수 있는 것으로 다루십시오. 체크리스트는 기억 보조이자 공유된 표준이지 판단의 대체물이 아닙니다. 해당하지 않는 항목은 삭제하고 영역에 필요한 항목을 더하십시오.

잘 쓰기 위한 안내:

• 체크리스트는 사람들이 실제로 끝낼 만큼 짧게 유지하십시오. 체크리스트가 일상적으로 건너뛰어진다면 너무 길거나 너무 일반적입니다.
• 기계가 검증할 수 있는 항목(서식, 테스트, 스캔)은 자동화해서 사람의 주의가 판단 항목에 쓰이게 하십시오.
• 체크리스트에 버전을 매기고 주기적으로 리뷰하십시오. 결코 바뀌지 않는 체크리스트는 아마 쓰이지 않고 있을 것입니다.
• 프로세스에서 구별이 중요할 때는 차단 항목과 권고 항목을 구별하십시오.

코드 리뷰 체크리스트

다른 사람의 변경을 검토하는 리뷰어를 위한 것입니다.

• 변경이 설명과 연결된 티켓이 말하는 대로 동작한다.
• 범위가 하나의 논리적 관심사에 집중되어 있고, 관련 없는 변경은 분리되어 있다.
• 설계가 기존 아키텍처에 맞고 피하기 쉬운 결합을 들여오지 않는다.
• 행복한 경로만이 아니라 경계 사례, 오류 경로, 실패 모드가 처리된다.
• 테스트가 있고, 의미가 있으며, 행위가 퇴보하면 실패할 것이다.
• 이름, 구조, 주석이 미래의 독자가 코드를 이해하게 한다.
• 비밀, 자격 증명, 토큰, 개인 데이터가 커밋되지 않았다.
• 보안에 민감한 입력이 적절히 검증, 인코딩, 매개변수화되어 있다.
• 공개 인터페이스, 계약, 하위 호환성이 보존되거나 의도적으로 버전이 매겨져 있다.
• 로깅, 지표, 오류 보고가 프로덕션에서 변경을 운영하기에 충분하다.
• 문서, 런북, 구성이 변경에 맞게 갱신되어 있다.
• 피드백이 차단 문제와 제안으로 구분되고, 코드에 관해 표현되어 있다.

풀 리퀘스트 작성자 체크리스트

리뷰를 요청하기 전의 작성자를 위한 것입니다.

• PR이 한 번에 주의 깊게 리뷰할 수 있을 만큼 작고 집중되어 있다.
• 설명이 무엇이 바뀌었고, 왜이며, 어떻게 검증했는지 진술한다.
• 연결된 티켓, 이슈, 설계 문서가 리뷰어에게 필요한 맥락을 준다.
• 모든 자동화된 점검이 로컬이나 CI에서 통과한다(빌드, 린트, 서식, 테스트, 스캔).
• 새로운 행위와 바뀐 행위가 테스트로 덮인다.
• 기계적 리팩터링이 행위 변경과 분리되어 있다.
• 자기 리뷰가 끝났다. 자신의 diff를 줄 단위로 읽었다.
• 디버그 코드, 주석 처리된 블록, 비밀, 떠도는 파일이 남아 있지 않다.
• 데이터베이스 마이그레이션, 기능 플래그, 구성 변경이 문서화되어 있고 되돌릴 수 있다.
• 깨지는 변경이 이전 경로와 함께 명시적으로 밝혀져 있다.
• 리뷰에 도움이 되는 곳에는 스크린샷, 녹화, 샘플 출력이 포함되어 있다.
• 알맞은 리뷰어와 필요한 역할 기반 승인자가 요청되어 있다.

완료의 정의 (Definition of Done)

작업 항목이 완료로 간주되기 전에 충족해야 하는 공유된 표준입니다.

• 티켓의 인수 기준이 모두 충족되고 시연할 수 있다.
• 코드가 동료 리뷰를 거쳐 필요한 리뷰어에게 승인되었다.
• 자동화된 테스트가 작성되고, 통과하고, 변경과 함께 병합되었다.
• 코드가 메인라인에 병합되고 파이프라인을 통해 깔끔하게 배포된다.
• 합의된 심각도 임계값의 알려진 결함이 열려 있지 않다.
• 문서, 도움말 텍스트, 런북이 갱신되었다.
• 관측 가능성이 갖춰져 있다. 관련 로그, 지표, 알림이 있다.
• 보안과 프라이버시의 함의가 고려되고 다뤄졌다.
• 사용자 대면인 경우 변경의 접근성 요구 사항이 충족된다.
• 기능 플래그가 구성되고 롤아웃 계획이 합의되었다.
• 프로덕트 오너나 이해관계자가 성과를 수용했다.
• 후속 작업이 암묵적으로 남겨지지 않고 추적되는 티켓으로 포착되어 있다.

프로덕션 출시 / 가동 준비

의미 있는 변경이나 새 서비스를 프로덕션에 출하하기 전의 것입니다.

• 롤아웃 계획이 단계적 또는 카나리 단계와 성공 기준을 포함해 문서화되어 있다.
• 롤백 계획이 문서화되고, 테스트되었으며, 빠르게 실행할 수 있다.
• 용량 및 부하 테스트가 시스템이 예상 수요와 피크 수요를 충족함을 보인다.
• 모니터링, 대시보드, 알림이 라이브이고 출시 전에 검증되었다.
• 온콜 커버리지가 일정에 잡혀 있고 대응자가 시스템을 안다.
• 가장 있을 법한 실패와 운영 시나리오에 대한 런북이 있다.
• 의존성, 통합, 제3자가 준비되었음이 확인되고 속도 제한이 이해되어 있다.
• 보안 리뷰와 필요한 승인이 완료되었다.
• 데이터 이전이 있다면 검증된 철수와 함께 종단 간 테스트되었다.
• 기능 플래그가 재배포 없이 변경을 끌 수 있게 한다.
• 필요한 곳에서 법무, 프라이버시, 컴플라이언스 승인을 얻었다.
• 커뮤니케이션 계획이 이해관계자, 지원, 고객을 덮는다.
• 진행/중단 결정이 이름 붙은 소유자들에 의해 명시적 기준에 대해 이루어진다.

보안 리뷰 / 위협 모델 체크리스트

변경이나 시스템의 보안 태세를 평가하기 위한 것입니다.

• 신뢰 경계와 데이터 흐름이 식별되고 문서화되어 있다.
• 인증이 그것이 필요한 모든 진입점에서 시행된다.
• 권한 검사가 모든 행동과 리소스에 최소 권한을 시행한다.
• 모든 외부 입력이 검증되고 출력이 그 목적지에 맞게 인코딩된다.
• 비밀이 관리되는 볼트에 저장되고 코드나 구성에 있지 않으며 교체할 수 있다.
• 분류가 요구하는 대로 데이터가 전송 중과 저장 시 암호화된다.
• 의존성이 알려진 취약점에 대해 스캔되고 최신으로 유지된다.
• 신뢰할 수 없는 입력에 대해 인젝션, 역직렬화, SSRF 위험이 완화된다.
• 보안 관련 이벤트가 민감한 데이터를 기록하지 않고 로깅된다.
• 속도 제한, 할당량, 남용 방지가 노출된 엔드포인트를 지킨다.
• 오류 메시지가 스택 트레이스, 내부 정보, 민감한 세부 사항을 새어 나가게 하지 않는다.
• STRIDE나 유사한 방법으로 식별된 위협이 완화나 수용된 위험과 함께 기록된다.
• 보안 테스트(SAST, DAST, 침투 테스트)가 계획되었거나 완료되었다.

프라이버시 및 데이터 보호(DPIA식) 체크리스트

개인 데이터나 민감한 데이터를 다루는 처리를 위한 것입니다.

• 수집하는 개인 데이터가 목록화, 분류되고 필요한 것으로 최소화된다.
• 각 처리 목적의 적법한 근거나 권한이 문서화되어 있다.
• 목적 제한이 시행된다. 데이터는 명시된 목적으로만 쓰인다.
• 보존 기간이 정의되고 삭제나 익명화가 자동화되어 있다.
• 정보 주체의 권리(열람, 정정, 삭제, 이동)를 이행할 수 있다.
• 동의에 의존하는 곳에서 동의는 자유롭게 주어지고, 구체적이며, 철회할 수 있다.
• 제3자와 처리자가 적절한 데이터 보호 조건에 구속된다.
• 국경 간 이전에 적절한 법적 이전 메커니즘이 있다.
• 개인 데이터에 대한 접근이 제한되고, 기록되고, 리뷰된다.
• 개인에 대한 프라이버시 위험이 평가되고 완화되거나 에스컬레이션된다.
• 데이터 침해 탐지와 통지 프로세스가 정의되어 있다.
• 설계 및 기본값에 의한 프라이버시 선택이 기능에 대해 문서화되어 있다.
• 필요한 곳에서 데이터 보호 책임자나 프라이버시 리뷰어가 승인했다.

접근성(WCAG) 체크리스트

WCAG 원칙에 맞춘 사용자 대면 인터페이스를 위한 것입니다.

• 모든 콘텐츠에 키보드만으로 닿고 조작할 수 있다.
• 포커스 순서가 논리적이고 눈에 보이는 포커스 표시기가 있다.
• 텍스트 색 대비가 목표 비율을 충족한다(본문 텍스트는 보통 4.5:1).
• 이미지와 비텍스트 콘텐츠에 의미 있는 대체 텍스트가 있다.
• 양식 필드에 연결된 레이블과 분명한 오류 메시지가 있다.
• 제목, 랜드마크, 구조가 의미론적으로 마크업되어 있다.
• 상호작용 구성 요소가 보조 기술에 올바른 이름, 역할, 상태를 노출한다.
• 콘텐츠가 200% 확대와 작은 화면에서 재배치되고 사용 가능한 상태로 남는다.
• 시간 제한을 조정할 수 있고 움직임이나 자동 재생 콘텐츠를 멈출 수 있다.
• 색이 정보를 전달하는 유일한 수단이 아니다.
• 미디어에 자막이 있고, 필요한 곳에는 대본이나 음성 해설이 있다.
• 인터페이스가 스크린 리더와 자동화된 접근성 도구로 테스트된다.

API 설계 리뷰 체크리스트

API를 게시하거나 변경하기 전의 것입니다.

• 리소스와 연산 이름이 일관되고 예측 가능하다.
• 계약이 기계가 읽을 수 있는 스키마(예: OpenAPI)로 명세되어 있다.
• 버전 전략이 정의되어 있고 하위 호환성이 보존되거나 관리된다.
• 페이지 매김, 필터링, 정렬이 일관된 관례를 따른다.
• 오류 응답이 일관된 구조, 코드, 행동 가능한 메시지를 쓴다.
• 인증과 권한 부여가 모든 연산에 명세되어 있다.
• 입력 검증과 크기 제한이 정의되고 시행된다.
• 재시도가 예상되는 연산에 멱등성이 정의되어 있다.
• 속도 제한, 할당량, 스로틀링 행동이 문서화되어 있다.
• 타임아웃, 재시도, 실패 의미가 클라이언트에게 분명하다.
• 응답의 민감한 데이터 노출이 최소화되고 정당화된다.
• 문서가 각 연산과 오류 사례에 대한 예시를 포함한다.
• 폐기 정책과 종료 일정이 정의되어 있다.

아키텍처 결정(ADR) 리뷰 체크리스트

제안된 아키텍처 결정 기록을 검토하기 위한 것입니다.

• 맥락과 풀려는 문제가 분명히 진술되어 있다.
• 결정이 단일 선택으로 모호하지 않게 진술되어 있다.
• 적어도 두 개의 현실적인 대안이 검토되고 비교되었다.
• 긍정적이고 부정적인 결과가 모두 문서화되어 있다.
• 비기능적 영향(성능, 보안, 비용, 운영 가능성)이 다뤄진다.
• 결정이 기존 원칙과 이전 ADR에 정렬되거나, 명시적으로 대체한다.
• 영향받는 팀과 이해관계자와 협의했다.
• 되돌릴 수 있음과 변경 비용이 평가되었다.
• 가정과 제약이 명시되어 있다.
• 상태(제안됨, 수락됨, 대체됨)가 설정되고 날짜가 매겨져 있다.
• 결정을 찾을 수 있고 관련 시스템에서 링크되어 있다.
• 후속 행동이나 이전이 추적되는 작업으로 포착되어 있다.

인시던트 대응 체크리스트

진행 중인 프로덕션 인시던트 동안의 것입니다.

• 인시던트를 선언하고 단일 인시던트 지휘관을 배정한다.
• 심각도, 범위, 고객 영향을 평가하고 소통한다.
• 전용 커뮤니케이션 채널과 인시던트 기록을 연다.
• 분명한 역할을 배정한다. 지휘관, 커뮤니케이션 리드, 운영 리드.
• 근본 원인 분석보다 완화와 서비스 복원을 우선한다.
• 정해진 주기로 이해관계자에게 정기적 상태 업데이트를 게시한다.
• 사건, 행동, 결정의 타임라인을 일어나는 대로 포착한다.
• 필요할 때 추가 대응자나 벤더에게 에스컬레이션한다.
• 데이터나 규제가 관련되면 법무, 보안, 컴플라이언스에 통지한다.
• 수정을 검증하고 시스템이 완전히 복구되었음을 확인한다.
• 인시던트를 공식적으로 종결하고 해결을 소통한다.
• 사람들이 흩어지기 전에 비난 없는 사후 검토를 일정에 잡는다.

사후 검토 체크리스트

인시던트 뒤의 회고 리뷰를 위한 것입니다.

• 리뷰가 비난 없이 이루어지고 시스템과 기여 요인에 초점을 맞춘다.
• 인시던트의 사실적이고 타임스탬프가 있는 타임라인이 문서화되어 있다.
• 고객과 비즈니스 영향이 수량화되어 있다(기간, 범위, 비용).
• 탐지가 분석된다. 문제가 어떻게, 언제 알려졌는가.
• 대응이 분석된다. 무엇이 도움이 되었고 무엇이 복구를 늦췄는가.
• 단일 근본 원인만이 아니라 기여 원인이 식별된다.
• 잘못된 것뿐 아니라 잘된 것도 기록된다.
• 행동 항목이 구체적이고, 소유자가 배정되고, 기한이 있다.
• 행동 항목이 예방, 탐지, 완화를 다룬다.
• 후속 항목이 일반 백로그에서 완료까지 추적된다.
• 사후 검토가 다른 사람들이 배울 수 있도록 널리 공유된다.
• 인시던트 전반의 체계적 패턴이 주기적으로 리뷰된다.

온콜 준비도 체크리스트

누군가 온콜 교대를 맡기 전의 것입니다.

• 대응자가 필요한 모든 시스템, 대시보드, 도구에 접근할 수 있다.
• 알림이 대응자에게 안정적으로 닿고 테스트되었다.
• 에스컬레이션 경로와 2차 온콜 연락처가 알려져 있고 최신이다.
• 가장 흔하고 가장 심각한 알림에 대한 런북이 있다.
• 대응자가 이 시스템들에 대한 온보딩이나 섀도잉을 마쳤다.
• 최근 변경, 진행 중인 인시던트, 알려진 문제가 인계되었다.
• 알림 임계값이 잡음과 거짓 호출을 최소화하도록 튜닝되어 있다.
• 대응자가 인시던트를 선언하고 지휘관에게 닿는 방법을 안다.
• 대응자의 작업 환경에서 프로덕션에 접근할 수 있다.
• 커뮤니케이션 채널과 이해관계자 연락처가 문서화되어 있다.
• 온콜 일정이 게시되어 있고 커버리지에 틈이 없다.
• 온콜의 보상, 기대, 업무량 한도가 분명하다.

SLO 정의 체크리스트

서비스 수준 목표를 정의할 때의 것입니다.

• SLO가 보호하는 사용자 여정이나 역량이 분명히 식별되어 있다.
• 서비스 수준 지표(SLI)가 분명하고 측정 가능한 양으로 정의되어 있다.
• 가능한 곳에서 SLI가 사용자의 관점에서 측정된다.
• 목표가 100%가 아니라 사용자가 실제로 필요로 하는 수준으로 정해져 있다.
• 측정 윈도(예: 롤링 28일)가 명시되어 있다.
• 목표에서 도출한 오류 예산이 계산되고 이해되어 있다.
• 오류 예산이 소진되면 무슨 일이 일어나는지 정책이 정의한다.
• SLI의 데이터 원천이 신뢰할 수 있고 계측되어 있다.
• 알림이 임계값 위반만이 아니라 소진율에 묶여 있다.
• 소유자와 이해관계자가 SLO가 현실적이고 의미 있다고 합의한다.
• SLO가 문서화되어 있고 대시보드에서 보인다.
• 서비스가 진화함에 따라 SLO를 리뷰하고 수정할 일정이 있다.

CI/CD 파이프라인 체크리스트

지속적 통합과 전달 파이프라인을 위한 것입니다.

• 모든 커밋이 자동화된 빌드와 테스트 실행을 촉발한다.
• 파이프라인이 빠르게 실패하고 결과를 작성자에게 분명히 보고한다.
• 린팅, 서식, 정적 분석이 자동으로 실행된다.
• 단위, 통합, 관련 종단 간 테스트가 파이프라인에서 실행된다.
• 보안 및 의존성 스캔이 모든 빌드에서 실행된다.
• 빌드 산출물이 버전이 매겨지고, 불변이며, 레지스트리에 저장된다.
• 비밀이 안전하게 주입되고 로그에 결코 출력되지 않는다.
• 배포가 환경 전반에서 자동화되고 반복 가능하다.
• 배포 전략(카나리, 블루-그린, 롤링)이 정의되고 쓰인다.
• 롤백이 자동화되었거나 문서화된 단일 행동이다.
• 파이프라인 권한이 최소 권한을 따르고 감사 가능하다.
• 파이프라인 구성이 코드로서 버전 관리에 저장된다.
• 필요한 곳에서 빌드 출처와 소프트웨어 자재 명세서가 생성된다.

코드형 인프라 리뷰 체크리스트

코드로 정의된 인프라를 검토하기 위한 것입니다.

• 변경이 전적으로 코드로 표현되고 파이프라인을 통해 적용된다.
• 적용 전에 계획이나 드라이런 출력이 리뷰된다.
• 상태가 동시 변경을 막는 잠금과 함께 안전하게 저장된다.
• 리소스가 이름, 태깅, 소유권 관례를 따른다.
• 최소 권한 IAM 역할과 정책이 쓰이고, 피할 수 있는 곳에는 와일드카드가 없다.
• 네트워크 노출이 최소화되고 의도하지 않은 공개 접근이 없다.
• 비밀과 민감한 값이 하드코딩되지 않고 볼트에서 참조된다.
• 저장소, 데이터베이스, 전송에 암호화가 켜져 있다.
• 변경이 멱등이고 다시 적용해도 안전하다.
• 피해 범위가 이해되고 파괴적 변경이 밝혀져 있다.
• 변경의 비용 영향이 고려된다.
• 모듈이 재사용 가능하고, 버전이 매겨지고, 테스트된다.
• 대역 외 변경을 잡도록 드리프트 탐지가 갖춰져 있다.

AI/ML 모델 릴리스 체크리스트

머신러닝 모델을 프로덕션에 릴리스하기 전의 것입니다.

• 모델의 의도된 용도, 범위, 한계가 문서화되어 있다.
• 학습 및 평가 데이터의 출처, 라이선스, 동의가 검증되었다.
• 데이터와 모델이 버전이 매겨지고 재현 가능하다.
• 성능이 대표적이고 따로 둔 테스트 데이터로 평가된다.
• 공정성과 편향이 관련 하위 집단 전반에서 평가된다.
• 모델이 현행 모델이나 기준선에 대해 평가된다.
• 실패 모드, 경계 사례, 분포 밖 행동이 이해되어 있다.
• 안전, 오용, 해로운 출력 위험이 평가되고 완화된다.
• 드리프트, 데이터 품질, 성능 저하에 대한 모니터링이 갖춰져 있다.
• 이전 모델이나 규칙 기반 경로로의 롤백이나 대체 경로가 있다.
• 중대한 결정에 사람의 감독이나 이의 제기가 제공된다.
• 프라이버시 리뷰가 학습 데이터와 추론 입력 및 출력을 덮는다.
• 이해관계자를 위해 모델 카드나 그에 상당하는 문서가 게시된다.

데이터 파이프라인 품질 체크리스트

분석이나 제품에 공급하는 데이터 파이프라인을 위한 것입니다.

• 원천 데이터 스키마가 검증되고 스키마 변경이 탐지된다.
• 수집이 늦거나, 중복되거나, 순서가 어긋난 레코드를 올바르게 처리한다.
• 데이터 품질 점검(완전성, 고유성, 범위)이 자동으로 실행된다.
• 실패한 레코드가 조용히 버려지지 않고 격리되어 표면화된다.
• 변환이 대표적이고 경계 사례인 입력으로 테스트된다.
• 파이프라인이 멱등이고 실패 뒤 다시 실행해도 안전하다.
• 출력의 신선도와 지연이 기대에 대해 모니터링된다.
• 소비자가 데이터의 출처를 알 수 있도록 계보가 문서화된다.
• 개인 및 민감한 데이터가 분류되고, 마스킹되거나, 적절히 제한된다.
• 백필과 재처리가 지원되고 문서화되어 있다.
• 알림이 소유자에게 실패와 품질 위반을 알린다.
• 보존 및 삭제 정책이 저장된 데이터에 시행된다.
• 하류 소비자와 SLA가 문서화되어 있다.

오픈 소스 도입 및 라이선스 리뷰 체크리스트

오픈 소스 구성 요소를 채택하기 전의 것입니다.

• 구성 요소의 라이선스가 식별되고 승인된 목록에 있다.
• 라이선스 의무(귀속 표시, 카피레프트, 고지)가 이해되고 충족된다.
• 배포 모델과의 라이선스 호환성이 확인된다.
• 프로젝트가 활발히 유지되고 건강한 커뮤니티가 있다.
• 알려진 취약점이 점검되고 버전이 최신이다.
• 의존성과 그 전이적 의존성의 목록이 만들어져 있다.
• 보안 태세와 과거 인시던트 이력이 리뷰된다.
• 구성 요소가 상당한 중복 없이 실제 필요를 채운다.
• 구성 요소의 퇴출 비용과 교체 가능성이 고려된다.
• 구성 요소가 소프트웨어 자재 명세서에 기록된다.
• 이름 붙은 소유자가 업데이트와 권고를 추적할 책임이 있다.
• 수정한 경우 되돌려 기여와 내부 포크 정책이 지켜진다.

벤더 / 제3자 위험 체크리스트

외부 벤더나 서비스를 온보딩하기 전의 것입니다.

• 비즈니스 필요와 벤더가 접근할 데이터가 분명히 정의되어 있다.
• 벤더의 보안 태세가 평가된다(인증, 감사, 설문지).
• 데이터 처리 조건, 소유권, 퇴출 시 삭제가 계약상 분명하다.
• 벤더의 하위 처리자와 데이터 위치가 공개되고 수용 가능하다.
• 관련 규정 준수가 검증된다.
• 가동 시간, 지원, SLA 약속이 문서화되어 있다.
• 침해 통지 의무와 시한이 계약에 있다.
• 접근이 최소 권한으로 한정되고 철회할 수 있다.
• 업무 연속성과 벤더 실패의 영향이 평가된다.
• 종속을 피하는 퇴출 및 데이터 이전 계획이 있다.
• 비용, 갱신 조건, 가격 변경 조항이 이해되어 있다.
• 벤더가 리뷰 날짜와 함께 위험 등록부에 추가된다.

정부 컴플라이언스(ATO / FedRAMP식) 준비도 체크리스트

운영에 공식 인가가 필요한 시스템을 위한 것입니다.

• 시스템 경계와 데이터 흐름이 정의되고 도식화되어 있다.
• 데이터가 영향 수준과 민감도로 분류되어 있다.
• 적용 가능한 통제 기준선이 선택되고 맞춤화되어 있다.
• 시스템 보안 계획이 각 통제가 어떻게 구현되는지 문서화한다.
• 통제가 구현되고, 증빙되고, 계획에 매핑되어 있다.
• 지속적 모니터링과 취약점 스캔이 운영 중이다.
• 조치 및 마일스톤 계획이 열린 발견 사항을 시정까지 추적한다.
• 접근 통제, 감사 로깅, 신원 관리가 요구 사항을 충족한다.
• 암호화가 승인된 알고리즘과 검증된 모듈을 쓴다.
• 인시던트 대응 계획이 문서화되고 테스트되어 있다.
• 비상 및 재해 복구 계획이 문서화되고 테스트되어 있다.
• 통제에 대한 독립 평가나 감사가 완료되었다.
• 인가 책임자에게 인가를 부여하는 데 필요한 위험 평가가 있다.
• 재인가 촉발 조건과 지속적 인가 주기가 정의되어 있다.