paint-brush
CTO가 SOC 2 규정 준수에 대해 알아야 할 3가지~에 의해@mikedekock
571 판독값
571 판독값

CTO가 SOC 2 규정 준수에 대해 알아야 할 3가지

~에 의해 Mike DeKock5m2024/08/03
Read on Terminal Reader

너무 오래; 읽다

최근 몇 년 동안 데이터 보안 환경이 크게 발전하여 SOC 2 보고서에 대한 수요가 증가했습니다. 고객은 제3자 감사를 통해 검증된 강력한 보안 프로그램이 마련되어 있다는 투명성과 확신을 기대합니다. 오늘날 우리가 알고 있는 SOC 2 보고서는 2010년 AICPA에서 개발되었습니다.
featured image - CTO가 SOC 2 규정 준수에 대해 알아야 할 3가지
Mike DeKock HackerNoon profile picture
0-item

마이크 드콕 , 창립자 겸 CEO MJD 고문


압도적인 사이버 공격에 맞서 시스템을 봉쇄해야 한다는 요구로 인해 데이터 보안이 강화됨에 따라 더 많은 스타트업이 SOC 2 보고서를 통해 고객에게 사이버 위생을 입증했습니다. 많은 사람들이 자신의 능력을 향상시키기 위해 그렇게 합니다. 사업 기회 . 그러나 감사 프로세스는 피하고 싶은 어려운 요구 사항으로 묘사되었기 때문에 여전히 문제가 있을 수 있습니다.


사실, 컴플라이언스 부문은 최근 몇 년간 비즈니스 요구 사항에 맞춰 대규모 변화를 겪고 있으며, 이는 기업이 데이터 보안을 입증하는 방법을 완전히 변화시켰습니다. 예를 들어, 증거 수집은 더 이상 수동으로 수행되지 않으며, 과거에는 관련된 모든 사람의 많은 노력과 시간이 필요했습니다. GRC(거버넌스, 위험 및 규정 준수) 소프트웨어는 이제 이러한 작업을 자동화하여 운영 뒤에서 실행합니다. 또한 이는 호황을 누리고 있는 시장이기도 합니다. 376억 3천만 달러 앞으로 4년 안에.


그럼에도 불구하고 기업은 비즈니스의 안녕을 위해서가 아니라 감사인을 기쁘게 하기 위해 하룻밤 사이에 운영 방식을 바꾸는 데 의존하는 등 오해가 높습니다. 일시적으로 도움이 되기는 하지만 이는 올바른 규정 준수로 얻을 수 있는 것은 아닙니다. 대신, 모범 사례를 선보이고 조직 내에서 긍정적인 변화를 창출하는 성장 촉진제처럼 보여야 합니다.


따라서 귀하가 CTO, 수석 엔지니어 또는 데이터 규정 준수를 담당하는 기타 비즈니스 리더라면 SOC 2 시험을 자신있게 수행할 수 있도록 세 가지 사항을 폭로하고 명확히 할 때입니다.

SOC 2에 대해 알고 있는 것은 과거의 일입니다

SOC 2의 역사 1970년대까지 거슬러 올라간다 , 이는 2010년에 제정된 비교적 새로운 규정 준수 표준입니다. 거의 15년이 지났지만 프로세스는 마지막 몇 년 동안만 극적으로 바뀌었습니다. 끝없는 인쇄 화면과 보안 설문지 양식으로 채워지지 않습니다. 그러나 이것이 대다수의 사람들이 여전히 규정 준수를 인식하는 방식입니다.


대부분의 오해는 단순히 맥락이 부족하거나 시대에 뒤떨어진 것입니다. 오늘날 규정 준수 관리 도구 덕분에 프로세스가 훨씬 쉽고 원활해졌습니다. 이러한 프로그램은 수동적이고 시간이 많이 걸리는 작업을 자동화하는 데 특화되어 있어 작업이 자동화되고 비동기식으로 수행되므로 SOC 2 요구 사항을 충족하기 위해 긴 회의와 비즈니스 속도 저하가 필요하지 않습니다.


예를 들어 일부 GRC 플랫폼은 GitHub와 같은 널리 사용되는 개발자 도구와 연결하여 워크플로를 지속적으로 중단하지 않고 규정 준수 목적으로 일상 활동을 모니터링합니다. 이러한 도구를 사용하면 복잡한 감사 활동을 수행하는 데 걸리는 시간이 기하급수적으로 줄어들고 대신 가치와 효율성이 향상됩니다.


또한 작업을 자동화하면 감사자의 부담이 줄어들어 분석 작업에 더 많은 시간을 투자할 수 있습니다. 규정 준수에 대한 고도의 기술적 접근 방식은 검토 중인 프로그램이 무엇인지 이해하는 데에도 도움이 되었습니다. 결과적으로 이들은 기업이 더 나은 데이터 보안 관행과 GRC 도구를 채택하여 SOC 2 이상을 준수하는 데 도움을 줄 수 있는 전문가로 발전했습니다.

SOC 2는 생각만큼 요구 사항 집약적이지 않습니다.

기술 회사가 완료해야 하는 모든 규정 준수 요구 사항 중에 SOC 2에 관한 내용이 번역에서 누락되었습니다. 보다 엄격한 다른 감사와 달리 SOC 2 보고서는 반드시 준수해야 하는 표준 조건 체크리스트가 아니라 업계 및 고객 기반이 직면한 회사 요구 사항을 중심으로 구성됩니다. 간단히 말해서, 고객에게 약속한 보안 약속을 입증하기 위해 규칙을 만드는 것은 기업입니다.


모든 사람이 규제 기관에서 요구하는 매우 구체적인 관행을 준수해야 하는 규정 준수와는 직관에 반하는 것처럼 들리지만 실제로 이러한 자유로움 덕분에 SOC 2가 성공적인 규정 준수 보고서가 되었습니다. 이는 또한 SaaS와 같은 업계의 북미 기업이 보안 설문지보다 이를 선호하게 만든 이유이기도 합니다.


이러한 접근 방식은 보안 프레임워크로서 SOC 2가 모든 회사가 다르게 운영되고, 다양한 고객에게 서비스를 제공하고, 광범위한 제품 또는 서비스를 제공한다는 것을 인식하기 때문에 유리합니다. 모든 사람이 동일한 요구 사항을 따르기를 기대하는 것은 불가능합니다. 예를 들어 교육 기술 회사는 학생 데이터에 대한 액세스 제어에 중점을 두는 반면, 금융 서비스 회사는 금전 거래에 대한 데이터 암호화에 우선 순위를 둘 수 있습니다.


사실은 SOC 2가 5가지 신뢰 서비스 기준 , 그 중 하나만 필수입니다(보안 제어). 감사자와 만날 때 귀하의 제품에 대해 논의하고 충족해야 하는 기준과 제외하고 싶은 기준을 평가하게 됩니다. SOC 2는 필수 사항이 아니라 회사에 도움이 되는 비즈니스 결정이므로 요구 사항을 이해하고 준수할 기준을 현명하게 선택하는 것은 귀하에게 달려 있습니다.

단지 감사자를 만족시키기 위해 업그레이드하지 마십시오

수십 년 동안 감사 사업에 종사해 온 사람으로서 저는 모든 것을 보았습니다. 내가 너무 자주 목격하고 기업이 반드시 삼가야 할 것 중 하나는 감사자를 기쁘게 하기 위해 시험 직전에 보안 도구를 구입하는 것입니다. 보고서를 작성한 후에 이러한 도구를 보관하든 안 하든, 이를 테스트 통과를 위한 임시 반창고로 인식해서는 안 됩니다.


SOC 2는 고객과 잠재 고객에게 보안 상태에 대한 통찰력을 제공하기 위해 이미 수행 중인 관행과 프로세스의 인벤토리를 수행합니다. 침입 감지, 정적 코드 분석, 기타 취약성 관리 도구 등의 프로그램을 감사 목적으로 일시적으로 사용한다면 SOC 2 보고서로 고객을 실망시키고 오해를 불러일으킬 수도 있습니다. 결국, 기만적인 행위로 인해 회사에 해를 끼치게 될 수 있습니다.


대신, CTO는 감사관과 함께 앉아 가능한 한 투명하게 행동하도록 권장되어야 합니다. CTO는 약점을 지적하는 것이 아니라 이미 수행하고 있는 훌륭한 작업을 강조하기 위해 존재합니다. 예외가 발생한 경우 이는 감사자가 업무를 잘 수행했으며 귀하의 관행을 개선하고 더 나은 데이터 보안을 준수할 수 있는 솔루션을 제공했다는 의미입니다.


무엇보다도 감사를 통해 우수한 보안 관행을 구현함으로써 회사가 더 나은 거래를 성사시키고 향후 더 큰 성공을 거둘 수 있도록 하십시오. 누가 그걸 원하지 않겠습니까?


SOC 2 인식 변화가 하룻밤 사이에 일어나지는 않을 것이라는 점을 이해하지만, 새로운 접근 방식을 지지하여 더 많은 기업이 보안 관행을 선보일 의지와 자신감을 갖고 쉽게 참여할 수 있도록 하는 것이 중요합니다. 감사 회사는 스타트업 및 기술 산업의 속도에 빠르게 적응하여 규정 준수를 과거와 거의 비슷해 보이는 간소화된 요구 사항으로 만들고 있습니다.