감사인이 인정하는 변경 관리 증적
변경 관리는 어떤 감사에서든 가장 집중적으로 샘플링되는 통제 중 하나입니다. 엔지니어링 팀은 이를 잘 수행하는 경우가 많지만 증적은 제대로 남기지 못하는 경우가 많습니다. 감사인이 살펴보는 내용은 다음과 같습니다.
SOC 2 Type II 감사에서 변경 관리(CC8.1)는 가장 집중적으로 샘플링되는 통제 중 하나입니다. 감사인은 감사 기간 전체에서 변경 건을 골라, 각 변경이 운영 환경에 반영되기 전에 승인되고 테스트되고 검토되었음을 입증하도록 요구합니다. ISO 27001(A.8.32), PCI DSS(6.5.1, 6.5.2), NIS2 시행규정(6.4항)도 표현만 다를 뿐 같은 내용을 요구합니다. 엔지니어링 팀은 대개 실제 작업을 수행하지만, 빠지기 쉬운 것은 증적입니다.
감사인이 검증하는 항목
표본 변경 건에 대해 감사인은 다음을 확인하고자 합니다:
- 변경이 요청되고 설명되어 있을 것: 무엇을, 왜 변경하는지 적힌 티켓 또는 풀 리퀘스트.
- 작성자가 아닌 다른 사람이 검토했을 것: 직무 분리.
- 운영 반영 전에 테스트되었을 것, 결과 포함.
- 배포 전에 승인되었을 것.
- 배포된 내용이 승인된 내용과 일치할 것: 검토되지 않은 코드가 운영 환경에 반영되지 않았음.
- 모집단이 완전할 것: 인프라와 구성 변경을 포함해 모든 운영 변경이 이 절차를 거쳤음.
통과하는 증적
- 브랜치 보호: 메인 브랜치는 병합 전에 작성자가 아닌 사람의 승인 검토 최소 1건과 통과한 검사를 요구합니다. 설정을 내보내고 감사 기간 동안 변경되지 않았음을 보여 주십시오.
- 파이프라인 전용 배포: 운영 배포는 CI/CD를 통해 보호된 브랜치에서만 이루어지며, 엔지니어는 직접 푸시할 수 없습니다.
- 연결된 기록: 각 배포는 병합된 풀 리퀘스트와 연결되고, 그 풀 리퀘스트는 티켓과 연결됩니다.
- 동일한 규칙이 적용되는 코드형 인프라: 인프라 변경도 같은 추적 기록을 남깁니다.
- 감사 기간의 완전한 변경 목록: 배포 도구에서 추출하며, 감사인이 이 목록에서 표본을 추출할 수 있어야 합니다.
긴급 변경
모든 절차에는 인시던트를 위한 빠른 경로가 필요하며, 감사인도 이를 기대합니다. 누가 승인할 수 있는지, 사후 검토를 얼마나 빨리 진행하는지(영업일 1~2일 이내가 일반적입니다), 변경이 인시던트와 어떻게 연결되는지를 정의하십시오. 그런 다음 긴급 변경이 실제로 드물게 발생하도록 관리하십시오.
감사에서 실패하는 사례
- 운영 환경에 직접 접근할 수 있는 관리자가 때때로 파이프라인을 우회하는 경우.
- 자기 승인된 풀 리퀘스트, 또는 봇만 수행한 검토.
- 기록 없이 콘솔에서 이루어진 구성 변경.
- 감사 기간 중 "임시로" 꺼 둔 브랜치 보호.
- 변경에 더 많은 테스트가 필요했음에도 "CI 통과" 외에 테스트 증적이 없는 경우.
샘플링: 감사인이 실제로 하는 일
SOC 2 Type II에서 감사인은 일반적으로 감사 기간 동안의 운영 변경 모집단 전체를 요청하고, 표본(크기는 모집단과 감사인의 방법론에 따라 다름)을 선택한 뒤, 표본으로 뽑힌 각 변경에 대해 요청 내용, 작성자가 아닌 사람의 검토, 테스트 결과, 승인 기록, 배포 내용이 승인 내용과 일치한다는 증거를 요구합니다.
실무상 두 가지 결과가 따릅니다. 첫째, 모집단은 완전하고 내보낼 수 있어야 합니다. 변경이 둘 이상의 경로로 운영 환경에 도달할 수 있다면 모든 경로에 기록이 있어야 합니다. 둘째, 증적이 없는 표본 변경 한 건이라도 보고서에서 예외 사항이 됩니다. 감사 중에 증적을 재구성하기보다 증적이 자동으로 남도록 절차를 고치는 편이 비용이 적게 듭니다.
SOC 2 CC8.1 페이지에서 이 기준이 ISO 27001, PCI DSS, NIS2와 어떻게 대응되는지 확인할 수 있습니다.
하나의 절차, 모든 프레임워크
보유 데이터에서 변경 관리 요구사항은 프레임워크 간에 서로 연결되어 있습니다:
| 방향 | 매핑됨 | 매핑 없음 | ||
|---|---|---|---|---|
| SOC 2 보유 → NIS2 필요 | 47 / 49 (96%) | 1 | 1 | 보고서 → |
| NIS2 보유 → SOC 2 필요 | 37 / 61 (61%) | 0 | 24 | 보고서 → |
보호된 브랜치와 파이프라인 전용 배포를 갖춘 풀 리퀘스트 기반 절차는 SOC 2, ISO 27001, PCI DSS, NIS2를 함께 충족합니다. PCI DSS에는 몇 가지 추가 요구가 있습니다. 사전 운영 환경과 운영 환경의 분리(6.5.3), 실제 계정 데이터를 테스트 환경에 두지 않기(6.5.5), 중대한 변경 후 보안 요구사항 확인(6.5.2)입니다.
관련 요구사항은 보안 개발 주제를 참고하고, SOC 2, ISO 27001, PCI DSS에서 증적 재사용에 관한 글도 함께 보십시오.
질문
SOC 2에서 풀 리퀘스트를 변경 승인으로 인정받을 수 있나요?
보통은 저장소가 병합 전에 작성자가 아닌 사람의 검토를 강제하고, 배포가 승인된 코드로만 제한되며, 감사 기간 동안의 변경 표본에서 이를 입증할 수 있다면 인정받을 수 있습니다.
감사를 위해 긴급 변경은 어떻게 처리해야 하나요?
정의된 긴급 절차를 따르십시오. 필요하면 먼저 수정하고, 정해진 시간 내에 사후 검토와 승인을 진행하며, 변경을 그것을 정당화한 인시던트와 연결하는 기록을 남깁니다.
2026-10-27 기준 데이터: 본 게시물의 수치는 현재 대응표에서 계산되며, 대응표가 변경되면 함께 업데이트됩니다. 대응표 공개된 크로스워크(NIST, ENISA, CIS, PCI SSC)가 연결을 뒷받침합니다 · 편집 콘텐츠 대응 크로스워크가 없는 경우 ControlMapping의 판단이며, 그 사유가 표시됩니다. · CSF 2.0 성과 하나만 공유함: 검토할 가치는 있으나 매핑은 아님 · 보유 데이터에 매핑 없음 당사 데이터에 매핑된 항목이 없음. 대개 신규 작업이지만 적용 범위 안내를 확인하세요. 컴플라이언스 자문 아님.
관련 게시물
분석 · 2026-10-27APRA CPS 234와 ISO 27001: ISMS 적용 범위와 APRA 추가 요건ISO 27001 ISMS는 APRA의 CPS 234 거의 모든 항목을 다루지만, APRA는 이사회 책임, 제3자 보증, 엄격한 통보 기한을 추가로 요구합니다.
분석 · 2026-10-27DORA vs NIS2: 기존 NIS2 프로그램이 이미 다루는 범위DORA와 NIS2는 보안 내용의 대부분을 공유하지만, DORA는 등록부, 계약 조건, 위협 기반 테스트를 추가합니다. 조항별로 이어지는 내용을 정리했습니다.
분석 · 2026-10-1311개 보안 프레임워크의 MFA 요구사항 비교어떤 프레임워크가 MFA를 요구하는지, 대상과 강도는 어떠한지 확인하세요. PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2, HIPAA를 한눈에 비교합니다.